Add PRD and Use Case Catalog; file the gate-house request (T02-T04)

T02 — intake INFD-IN-0001 filed with gate-house and messages sent to gate-house,
key-cape and approval-engine. Status progress; it now waits on an external
ruling. key-cape was told explicitly why T07 is not answering KEY-WP-0013-T02
yet — a placeholder callback URI would either fail closed or register an origin
no component owns — and given the token shape to check now rather than at T07.

T03 — ProductRequirementsDocument.md. 30 requirements, each traced to a GOAL.md
DoD item, an INTENT principle or wrongness condition, a state-transition guard,
or a named external contract, and each with an observable pass condition.
Anti-requirements are stated as testable absences: no dwell timers, no attention
analytics, no dark patterns, no auto-approval, no approval-state caching, no
authorization endpoint. Four limitations are recorded up front, including that
escalate without a mandate graph is forwarding and that view_hash is computed by
the renderer.

T04 — UseCaseCatalog.md. L0-L5 with counterparties, plus ten negative cases
bound to guards and isolation vectors. Each case records the constraint it
places on the shared schema, so scale invariance is testable rather than
asserted. Closes with the four changes that would fork the object.

T05 and T07 remain gated on the ruling. T06 is independent and is next.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01V3W1dQG7GFFM9d94jFx7iR

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1565372@bnt-lap001
Assistant-Session: 16bb2f25-b34c-49ef-8e94-5fec3567a568
This commit is contained in:
tegwick 2026-09-09 14:11:36 +02:00
parent ebd35b59cf
commit b78c15a7ef
5 changed files with 686 additions and 3 deletions

View file

@ -80,7 +80,7 @@ Two corrections made during the same task, recorded rather than silently fixed:
```task
id: INFD-WP-0001-T02
status: todo
status: progress
priority: high
state_hub_task_id: "4f94134b-2260-5404-84e0-12f2b08ef565"
```
@ -118,7 +118,7 @@ recorded as a decision, not left implicit. Blocking for T05 and T07.
```task
id: INFD-WP-0001-T03
status: todo
status: done
priority: high
state_hub_task_id: "86465a35-1af5-5956-a767-57ad838dffa9"
```
@ -141,11 +141,23 @@ Acceptance: every requirement traces to either a `GOAL.md` definition-of-done
item or a named external contract; each requirement is testable; the document
names what it is deliberately not requiring and why.
Completed 2026-09-09: `docs/specs/ProductRequirementsDocument.md`. 30 numbered
requirements, each with a `trace:` line to a `GOAL.md` DoD item, an `INTENT.md`
principle or wrongness condition, a state-transition guard, or a named external
contract, and each with an observable pass condition. Anti-requirements
(PR-70..75) are stated as testable absences: no dwell timers, no attention
analytics, no dark patterns, no auto-approval, no approval-state caching, no
authorization endpoint. Four known limitations are recorded up front rather than
discovered later — chiefly that `escalate` without a mandate graph is forwarding
(L-01) and that `view_hash` is computed by the renderer, so a compromised
surface can present X and attest Y (L-02). Four open questions are left for
review rather than answered by assumption.
## Use Case Catalog
```task
id: INFD-WP-0001-T04
status: todo
status: done
priority: medium
state_hub_task_id: "00a83db5-fe0e-522a-b885-6f9ef034bc07"
```
@ -168,6 +180,14 @@ Acceptance: every use case maps onto the single Decision Memo schema with no
level-specific object; each negative case names the invariant it protects; the
catalog states for each level which estate repository would consume it.
Completed 2026-09-09: `docs/specs/UseCaseCatalog.md`. Six use cases L0-L5 with
counterparty and stage, ten negative cases each bound to a guard or isolation
vector, and a closing section naming the four changes that would fork the
object — a level-specific status, multiple questions per memo, a per-level
packet model, and an approvals-inbox entity that acquires state. Each case
records what it contributes as a *constraint* on the shared schema, so the
scale-invariance claim is checkable rather than asserted.
## Architecture Blueprint
```task