From 552650a69b71fe51c410708c4e2519e8a569f150 Mon Sep 17 00:00:00 2001 From: fred Date: Thu, 27 Aug 2026 04:12:05 -0500 Subject: [PATCH] =?UTF-8?q?contract(onboarding-wizard):=20revision=2013=20?= =?UTF-8?q?=E2=80=94=20seed-progress=20query,=20generalized=20designation-?= =?UTF-8?q?derived=20authority?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Addresses sol r12 verdict (NEW-18, NEW-19): - NEW-18: new mapped, designation-only seed-progress query returning exactly the next unrecorded canonical position index (or completion marker); screening evaluated before any fence state, non-designated submitters refused byte-shape-identically across recorded and unrecorded worlds; closed read set (position-committed existence flags + designation, §6.1); origin fresh-client resume and successor completion both query first and originate from the returned index. - NEW-19: designation-derived authority generalized to the actor-authorization component of every canonical position's owning family, each surface named expressly (contract 2 §4; RBAC §§2-3 workspace-content authorization; native-kanban SOT REQ-TEN-001 / A1 §8.1.3) as coupled severable-together amendments under one mechanically decidable scope, with a defined result-disclosure boundary (canonical outcome fields only). - §6.7: seed-progress two-world refusal, entitlement witness with the actual fresh client run against both worlds, content-position completion in both recovery variants, non-canonical content refusal, result-disclosure witness. - §7 item 12 now three coupled amendments; §1.1/§1.2/§5.3-5.4/§6.1 disclosures updated; preamble Revision 13 paragraph. --- docs/requirements/onboarding-wizard.md | 372 ++++++++++++++++++++----- 1 file changed, 303 insertions(+), 69 deletions(-) diff --git a/docs/requirements/onboarding-wizard.md b/docs/requirements/onboarding-wizard.md index 6b2c68cc..d50a3ab9 100644 --- a/docs/requirements/onboarding-wizard.md +++ b/docs/requirements/onboarding-wizard.md @@ -277,7 +277,55 @@ identity actually defines (NEW-14). §6.7 reworked: the two-world control now asserts equal event content, an empty grant-table delta, and a full-command timing bound; new self-revocation two-world refusal, designation-derived completion, post-completion -harmlessness, and post-succession replay witnesses. +harmlessness, and post-succession replay witnesses. (Revision 13 +generalizes the designation-derived authority — which this revision +scoped to contract 2 §4 only — across every canonical position's +owning family, and adds the seed-progress query that locates the +suffix.) + +Revision 13 (sol re-review 11: NEW-18, NEW-19): the designated +client can locate the suffix, and can originate all of it. +**Seed-progress query** (NEW-18): revision 12 made every canonical +tuple derivable but left the committed-prefix length underivable — +a fresh successor's permitted inputs were identical across an +empty-prefix world and a k-committed world, so §6.7's required +never-submit-a-committed-position walk was impossible without +hidden fixture state, and blind submission could not distinguish a +committed prefix from a real collision or authorization loss. §4.3 +now defines one mapped, designation-only read surface returning +exactly the epoch's next unrecorded canonical position index (or a +completion marker): the designation screening is evaluated before +any fence state, every non-designated submitter — former +designations and platform admins included — is refused +byte-shape-identically across recorded and unrecorded worlds, the +read set is closed to position-committed existence flags plus the +designation (§6.1), and the state-dependent answer for the +designated account is the entitled disclosure that is the query's +purpose. The original origin's fresh-client resume and the +successor's completion both query first and originate in order +from the returned index; no client infers progress from refusal +shapes. **Generalized designation-derived authority** (NEW-19): +revision 12's amendment reached only contract 2 §4's +hierarchy-authority component, so a grant-less designation — an +origin that revoked its own position-1 `owner` grant, or a +tenant-unprivileged successor — could originate hierarchy +positions but not the ordinary workspace-content example +positions, whose authorization lives in RBAC §§2–3 and the +native-kanban SOT. §7 item 12 now amends the actor-authorization +component of every canonical position's owning family expressly — +contract 2 §4; RBAC §§2–3; native-kanban SOT REQ-TEN-001 / +Amendment A1 §8.1.3 — coupled and severable together, under one +mechanically decidable scope (current designation, next unrecorded +canonical position, exact server-derived tuple, in-order fresh +origination) and a defined **result-disclosure boundary**: a +successful origination's response and recorded outcome carry +exactly the command's canonical outcome fields, and a +designation-only actor's non-canonical content command is refused +by the owning contract. Witnesses §6.7: seed-progress two-world +refusal, seed-progress entitlement with the actual fresh client +run against both worlds, content-position completion in both +recovery variants, non-canonical content refusal, and the +result-disclosure witness. Scope: the Gateway-backed product onboarding wizard. Out of scope: the host-local install wizard (`mosaic wizard`, which drives host install and @@ -312,8 +360,9 @@ through the extensibility rule §2.4). hierarchy commands and the rank-4 enrollment command (contract 5 §3.1 — built first), the settings command family (steps 1–2), the identity bootstrap and registration surface (step 3, including the - §3.3 finalize command and the §4.3 seed-origin succession - command), the mode reads (contract 6 §2.2 post-epoch; + §3.3 finalize command, the §4.3 seed-origin succession + command, and the §4.3 seed-progress query), the mode reads + (contract 6 §2.2 post-epoch; the §2.3 bootstrap-status field pre-epoch), and the ordinary content commands used for example seeding (step 4). Two of these families (ranks 1 and 4) are in contract 5 §3.1's live rank-6 @@ -334,12 +383,19 @@ through the extensibility rule §2.4). transaction — and the **§7 item 12 seed-origin succession command** (§4.3), one mutating epoch-record command whose closed write set is the designation update and its single audit event. Beyond those - two amendments, nothing is added to identity §3; the one further - disclosed authorization amendment is §7 item 12's - **designation-derived origination authority** — a scoped change to - contract 2 §4's evaluation for canonical seed origination only, - conferring no grant and no read authority — and no undisclosed - authority exists; all three surfaces appear in + two amendments, nothing is added to identity §3; the further + disclosed amendments are §7 item 12's + **designation-derived origination authority** — a scoped change, + for canonical seed origination only, to the actor-authorization + component of each canonical position's owning family (contract 2 + §4's hierarchy authority; RBAC §§2–3's workspace-content + authorization; the native-kanban SOT's workspace-scoped command + authorization, REQ-TEN-001 / Amendment A1 §8.1.3), conferring no + grant and no read authority — and §7 item 12's **seed-progress + query** (§4.3), one designation-only mapped read surface + disclosing exactly the epoch's next unrecorded canonical seed + position index (or a completion marker) and nothing else; no + undisclosed authority exists; all of these surfaces appear in the §1.1 composed-family inventory, the §7.8 mapping amendment, and §6.1's inventories, so the D8 mapping and authorization-parity witnesses cannot omit them. @@ -558,7 +614,17 @@ the named authority: would. Seeded examples are ordinary workspace content created by ordinary commands, attributable in audit to the acting admin, carrying the run's trace correlation ids (contract 5 §4.3) - and the §4.3 idempotency keys. + and the §4.3 idempotency keys; their actor-authorization + component — RBAC §§2–3's workspace-content authorization, and + the native-kanban SOT's workspace-scoped command authorization + (REQ-TEN-001, Amendment A1 §8.1.3) for the kanban example + positions — is, for canonical seed origination only, likewise + satisfied by the §4.3 designation-derived authority, under the + same mechanical scope and the §4.3 result-disclosure boundary + (§7 item 12); every other component of each content command's + evaluation (validation, eligibility, collision and replay + rules) is unchanged, and outside the canonical seed key set + every content command's authorization is untouched. 5. **Minimal agent enrollment.** One harness, API-key login, agent name and persona (D11). Enrollment specifics belong to the rank-4 agent-enrollment command family; this contract binds only that the @@ -718,17 +784,43 @@ collects no sensitive category, so v1 ships no custody surface. executing its seed mutation in order, passing the full fresh-mutation authorization for that seed command — §5.2 eligibility and identity §7.1 eligibility evaluated fresh - against the submitter, with the hierarchy-authority component + against the submitter, with the actor-authorization component satisfied by the **designation-derived authority**: for exactly the fresh origination of a currently-unoriginated canonical seed position, the current designation itself - satisfies the parent-`owner` (or top-level) authority contract - 2 §4 requires, a disclosed scoped amendment (§7 item 12) that - confers no read authority, no replay authority, no standing - grant, no authority over any committed record, and nothing - outside the canonical seed key set — evaluated per submission, - writes nothing; a refused submission records no row (no-error - replay below). The recorded actor of every shared row is + satisfies the actor-authorization component of the position's + **owning command family** — for the top-level and child + hierarchy positions, the parent-`owner` (or top-level) + authority contract 2 §4 requires; for the ordinary + workspace-content example positions, the workspace-content + authorization RBAC §§2–3 require and the workspace-scoped + command authorization the native-kanban SOT requires + (REQ-TEN-001, Amendment A1 §8.1.3) — coupled disclosed + amendments to each named surface (§7 item 12), severable + together, that confer no read authority, no replay authority, + no standing grant, no authority over any committed record, + and nothing outside the canonical seed key set. The + authority's scope is mechanically decidable per submission: + the submitter is the epoch's current designation, the + (operation, key) is the next unrecorded canonical position, + the payload and scope equal that position's server-derived + tuple exactly, and the submission is a fresh in-order + origination; every other component of the owning family's + evaluation (validation, §5.2 eligibility, identity §7.1 + eligibility, collision and replay rules) is evaluated fresh + and unchanged; the authority is evaluated per submission and + writes nothing beyond the command's own canonical writes; a + refused submission records no row (no-error replay below). + **Result-disclosure boundary.** A successful origination's + response and recorded outcome contain exactly the command's + canonical outcome fields — the created row id, any + canonical-reference-resolved parent id, the canonical key, + and the payload digest — and nothing else: no listing, no + attribute of any pre-existing record beyond the resolved + parent id the outcome must record, and no grant- or + fence-table content. Refusals on canonical seed keys are + screened by the seed-boundary gate first and keep its + constant shape. The recorded actor of every shared row is therefore the account that was the epoch's seed-origin at that position's origination, authorized for the mutation the row fences. Recorded positions are replayable by any admin holding @@ -807,13 +899,47 @@ collects no sensitive category, so v1 ships no custody surface. current designation: after succession the successor originates the remaining suffix in order under its own full fresh-mutation authorization (§4.3 designation-derived - authority plus its own eligibility), deriving every tuple from - canonical settings state alone — no replay of any committed - position is needed or implied — and the fence rows it + authority plus its own eligibility), locating that suffix + through the seed-progress query below and deriving every + tuple from canonical settings state alone — no replay of any + committed position and no read of any recorded outcome is + needed or implied — and the fence rows it originates record the successor. Succession is repeatable across successive origin losses. Factory reset (§4.2) remains the only path to a new epoch; it is never required to complete an interrupted seed sequence. + - **Seed-progress query.** Locating the unoriginated suffix is a + disclosed, mapped read surface, never an inference from + refusal shapes: the **seed-progress query** returns exactly + one value — the index of the epoch's next unrecorded + canonical seed position, or a completion marker when every + position is recorded — and nothing else. It is authorized for + exactly the account the epoch's designation currently names, + and that screening is evaluated first, before any fence state + is consulted: every other submitter — a former designation, a + platform admin, and an admin holding target-result read + authority included — is refused with the same single + constant-shape bounded conflict as the seed-boundary gate, + byte-shape-identical whether any seed fence exists or not, so + the recorded and unrecorded worlds stay indistinguishable to + every non-designated actor and RBAC §7's no-existence-oracle + rule holds on this surface too. For the designated account + the returned index is intentionally state-dependent — that + disclosure is the query's purpose, and it is bounded: the + query reads only which canonical positions have committed + fence rows (position-committed existence) plus the epoch + record's designation, never a recorded outcome, a payload or + digest, a resolved id, an acting principal, or any grant + state, and its closed read set is statically asserted (§6.1). + The query writes nothing and appends no event. A resuming + designated client — the original origin on a fresh client and + a §4.3 successor alike — first submits the query and then + originates in order from the returned index, deriving each + tuple from canonical settings state alone; an admin holding + target-result read authority may instead walk the sequence + and receive recorded outcomes as replays (§6.3). No client is + required to infer progress from refusals, and no + non-designated actor can. - **No error replay.** The fence row commits only with its mutation, so only committed outcomes are ever recorded. A failed or refused submission records no fence row; a retry executes @@ -870,24 +996,30 @@ collects no sensitive category, so v1 ships no custody surface. individually atomic commands, not one transaction: an interruption between them leaves a prefix of committed seed nodes, and the §4.3 fence makes the resumed run complete exactly the remaining suffix — - the run re-derives the full ordered seed sequence from canonical - state and re-submits it with the same deterministic keys, - already-committed mutations return their recorded outcomes, and - only the remainder executes, without duplication and without - compensating rollback of completed commands. There is no + the resumed designated client locates that suffix through the + §4.3 seed-progress query and originates in order from the + returned index, re-deriving every tuple from canonical state; a + target-authorized admin's re-run may instead re-submit the full + ordered seed sequence with the same deterministic keys, + already-committed mutations returning their recorded outcomes — + either way only the remainder executes, without duplication and + without compensating rollback of completed commands. There is no wizard-level transaction spanning steps. Loss of the seed-origin account mid-sequence — identity §7.1 unavailability — is likewise recoverable without a new epoch: §4.3 seed-origin succession - designates an eligible successor, and the resumed run completes - the remaining suffix under the successor's designation-derived - authority, deriving every tuple from canonical settings state - alone — no grant is conferred and no committed position is - replayed. Succession is repeatable, so interrupted runs strand - nothing even across successive origin losses. Origination - authority is designation-derived (§4.3), never grant-dependent, - so no revocation — including an origin revoking its own - position-1 `owner` grant — can strand the suffix while the - origin remains available. + designates an eligible successor, and the resumed run locates + the remaining suffix through the §4.3 seed-progress query and + completes it under the successor's designation-derived + authority — the ordinary workspace-content example positions + included (§4.3, §7 item 12) — deriving every tuple from + canonical settings state alone: no grant is conferred and no + committed position is replayed. Succession is repeatable, so + interrupted runs strand nothing even across successive origin + losses. Origination authority — and suffix location, the §4.3 + seed-progress query — is designation-derived (§4.3), never + grant-dependent, so no revocation — including an origin + revoking its own position-1 `owner` grant — can strand the + suffix while the origin remains available. ## 5. Seeding authority (resolves contract 2 review NEW-1) @@ -917,6 +1049,18 @@ collects no sensitive category, so v1 ships no custody surface. origination, the parent-authority component is satisfied by the §4.3 designation-derived authority (§7 item 12); outside the canonical seed key set the rule is unchanged. +4. Example-content creation inside the wizard (the fixed §3.4 + example set) follows each item's owning content contract — RBAC + §§2–3's workspace-content authorization and, for the kanban + examples, the native-kanban SOT's workspace-scoped command + authorization (REQ-TEN-001, Amendment A1 §8.1.3) — with the + same canonical-seed-origination exception: for exactly those + positions, the actor-authorization component is satisfied by + the §4.3 designation-derived authority under §7 item 12's + mechanical scope and the §4.3 result-disclosure boundary. + Outside the canonical seed key set every content rule is + unchanged, and a designation-only actor's non-canonical content + command is refused by the owning contract (witness §6.7). ## 6. Verification requirements @@ -949,7 +1093,17 @@ Binding on the implementing PRs: write, nothing else; and the handler is statically asserted to read no fence table, no recorded outcome, no grant table, and no hierarchy record — its inputs are identity state, platform - eligibility, and the epoch record only (§4.3). Wizard modules appear in no + eligibility, and the epoch record only (§4.3). + **Seed-progress-query inventory:** the §4.3 seed-progress query + handler's read set is statically enumerated and asserted equal, + in both directions, to: the epoch record's current designation + (its authorization input, screened first) and the + position-committed existence flags of the epoch's canonical + seed keys — no recorded outcome, no payload or digest, no + resolved id, no acting principal, no grant table, no hierarchy + or content record; its write set is asserted empty (no event, + no row), and its response schema is closed to the single + index-or-completion value. Wizard modules appear in no class-table writer allowlist (contract 1 §6.3b) and hold no direct database or filesystem access (static assertion, plus a runtime probe that a wizard-context filesystem/database access attempt is @@ -1172,9 +1326,12 @@ Binding on the implementing PRs: changes to the successor with exactly one mutation audit event recording the prior designation, the new designation, and the acting principal — asserted to write no grant row and touch no - fence row — and the successor's resumed run derives the + fence row — and the successor's resumed run submits the §4.3 + seed-progress query — asserted to return exactly the first + unrecorded index — derives the remaining tuples from canonical settings state alone and - originates the suffix in order, never submitting a committed + originates the suffix in order from that index, never + submitting a committed position: zero replay access events name the successor, zero grant rows name the successor, the mutation count equals exactly the suffix length, the new fence rows record the successor, the @@ -1214,21 +1371,66 @@ Binding on the implementing PRs: in BOTH (the origin is available; grant state is not an input), with no event and no record change in either — proving no allowed grant change opens succession or leaks seed state; a - **designation-derived completion (NEW-12/NEW-13)** — origin A - originates a prefix, revokes its own position-1 `owner` grant, - and resumes: every remaining origination succeeds under the + **seed-progress two-world refusal (NEW-18)** — worlds U (no + seed position committed) and P (positions 1..k committed) agree + on identity, platform, and epoch state; a non-designated actor + — an eligible platform admin, a former designation after + succession, and an admin holding target-result read authority + each probed — submits the §4.3 seed-progress query in both + worlds and is refused byte-shape-identically in both, with no + event appended in either — proving the query surface discloses + nothing to anyone but the current designation; a + **seed-progress entitlement witness (NEW-18)** — the SAME + designated account submits the query in worlds U and P: it + returns 1 in U and k+1 in P (the intentional, entitled + disclosure), reading no outcome payload and no grant state + (asserted by the §6.1 closed read set); the actual fresh + client — holding no transient state, no bookkeeping cache, and + no seed read authority — is then run to completion against + BOTH worlds, and in each it originates first exactly the + returned index and completes the sequence without submitting + any committed position and without receiving a single refusal + in the walk — proving progress location is a disclosed entitled + read, never an inference from refusal shapes; a + **designation-derived completion (NEW-12/NEW-13/NEW-19)** — + origin A originates a prefix extending past workspace creation + — so the remaining suffix consists of ordinary + workspace-content example positions — revokes its own + position-1 `owner` grant, and resumes: the seed-progress query + returns the first unrecorded index and every remaining + origination, the content positions included, succeeds under the designation-derived authority, zero new grant rows are written beyond each command's own §5.2/§4.3 defaults, and the seed set - completes — proving completion never depends on a revocable - grant; a **tenant-unprivileged successor completion (NEW-13)** — - the successor of the two-world control's recorded world, who + completes — proving completion, content positions included, + never depends on a revocable grant; a **tenant-unprivileged + successor completion (NEW-13/NEW-19)** — + the successor of the two-world control's recorded world, whose + recorded prefix likewise extends past workspace creation, who held no seed-record authority before succeeding and receives - none by succeeding, completes the entire remaining suffix by - direct in-order origination using only the designation-derived + none by succeeding, completes the entire remaining suffix — + its workspace-content positions included — by + direct in-order origination from the seed-progress query's + returned index, using only the designation-derived authority plus its own eligibility; a subsequent read attempt by that successor against a committed pre-succession seed record is refused — proving succession recovers completion without - conferring read or tenant authority; a **post-completion + conferring read or tenant authority; a **non-canonical content + refusal (NEW-19)** — a designation holding no grant (the + self-revocation world, post-completion) submits, against the + seed workspace, an ordinary content command whose (operation, + key) is outside the canonical seed key set — a second, + non-canonical kanban item — and is refused by the owning + content contract's authorization with nothing written — proving + the designation-derived authority stops at the canonical set + and confers no general workspace authority; a + **result-disclosure witness (NEW-19)** — a successor's + content-position origination response and recorded outcome are + asserted to contain exactly the canonical outcome fields + (created row id, resolved parent id, canonical key, payload + digest) and no attribute of any pre-existing record beyond the + resolved parent id — proving origination under the + designation-derived authority discloses nothing further; a + **post-completion harmlessness control (NEW-16)** — with the seed sequence fully complete, the origin is banned and an eligible platform admin B submits succession: it succeeds with exactly one audit event, @@ -1395,9 +1597,9 @@ contracts and are not additions: rank-4 enrollment families, is amended to name all six composed families — adding the settings command family, the identity bootstrap and registration surface (including the §3.3 finalize - command and the §4.3 seed-origin succession command, so the - official-tool mapping and §6.1's authorization-parity witnesses - cannot omit either), the mode reads (contract 6 §2.2 and the §2.3 + command, the §4.3 seed-origin succession command, and the §4.3 + seed-progress query, so the official-tool mapping and §6.1's + witnesses can omit none of them), the mode reads (contract 6 §2.2 and the §2.3 bootstrap-status field), and the ordinary content commands used for example seeding — with one mapping row per newly named family. Without this amendment those operations are unmapped and blocked @@ -1426,9 +1628,9 @@ contracts and are not additions: provenance for §3.4's derivation; the current company name lives on the company row and changes only through the ordinary hierarchy rename (§3.1, witnesses §6.3). -12. The **seed-origin succession command and the - designation-derived origination authority** (§4.3) — two - coupled amendments, proposed and ratified here, severable +12. The **seed-origin succession command, the designation-derived + origination authority, and the seed-progress query** (§4.3) — + three coupled amendments, proposed and ratified here, severable together. First, an amendment to identity §3's epoch surface: one mutating command that redesignates the epoch's seed-origin to the submitter, valid only while the current origin is @@ -1451,21 +1653,53 @@ contracts and are not additions: recovery for existing records is expressly out of scope (§4.3). The command is repeatable (a later unavailable successor is succeeded the same way), and recorded fence rows - are never rewritten. Second, a scoped amendment to contract 2 - §4's authorization evaluation: the **designation-derived - origination authority** — for exactly the fresh origination of - a currently-unoriginated canonical seed position, the epoch - record's current designation itself satisfies the - parent-`owner` (or top-level) hierarchy-authority component of - fresh-mutation authorization; it confers no read authority, no - replay authority, no standing grant, no authority over any - committed record, and nothing outside the canonical seed key - set, is evaluated per submission, and writes nothing; every - other authorization component (§5.2 eligibility, identity §7.1 - eligibility) is evaluated fresh and unchanged. Together these - make origin loss recoverable with no escalation surface: - without them a banned seed-origin account strands the - unoriginated seed suffix, contradicting PRD D4's no-lock-in + are never rewritten. Second, the **designation-derived + origination authority** — a scoped amendment to the + actor-authorization component of every canonical seed + position's owning command family, each amended surface named + expressly: contract 2 §4's parent-`owner` and top-level + hierarchy-authority evaluation (the company, estate, project, + and workspace positions); RBAC §§2–3's workspace-content + authorization evaluation (the ordinary example-content + positions); and the native-kanban SOT's workspace-scoped + command authorization (REQ-TEN-001, Amendment A1 §8.1.3) for + the kanban example positions. For exactly the fresh + origination of a currently-unoriginated canonical seed + position, the epoch record's current designation itself + satisfies that one component; the scope is mechanically + decidable per submission — current designation, next + unrecorded canonical position, exact server-derived tuple, + in-order fresh origination — and every other component of each + family's evaluation (validation, §5.2 eligibility, identity + §7.1 eligibility, collision and replay rules) is evaluated + fresh and unchanged. It confers no read authority, no replay + authority, no standing grant, no authority over any committed + record, and nothing outside the canonical seed key set; it is + evaluated per submission and writes nothing beyond the + command's own canonical writes; and a successful origination's + response and recorded outcome are bounded to exactly the + command's canonical outcome fields (created row id, resolved + parent id, canonical key, payload digest) — the §4.3 + result-disclosure boundary. Third, the **seed-progress query** + (§4.3) — an addition to contract 5 §4's command-envelope + surface, the owning contract of the item 4 fence table whose + recording existence it reads: + one mapped read surface returning only the epoch's + next unrecorded canonical position index or a completion + marker, authorized for exactly the current designation, the + screening evaluated before any fence state with every + non-designated submitter refused with the constant-shape + conflict byte-shape-identically across recorded and unrecorded + worlds; its closed read set (the designation plus + position-committed existence flags, §6.1) covers no recorded + outcome, no grant state, and no content, and it writes + nothing. Together these make origin loss recoverable with no + escalation surface and no oracle: without the succession + command a banned seed-origin account strands the unoriginated + seed suffix; without the generalized authority the suffix's + content positions refuse for a grant-less designation; and + without the query no fresh designated client can locate the + suffix at all — each contradicting PRD D4's no-lock-in requirement (§4.4). ## Ruling request