mosaicstack/stack
18
0
Fork 1
Code Issues 335 Pull Requests 14 Actions Packages Projects Releases 15 Wiki Activity

contract(onboarding-wizard): revision 13 — seed-progress query, generalized designation-derived authority
ci/woodpecker/pr/ci Pipeline was successful
Details

Browse Source 
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.
This commit is contained in:
fred
2026-08-27 04:12:05 -05:00
parent 10e82d05c0
commit 552650a69b
1 changed files with 303 additions and 69 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/requirements/onboarding-wizard.md
+303 -69
View File
@@ -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