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:
parent
ebd35b59cf
commit
b78c15a7ef
5 changed files with 686 additions and 3 deletions
|
|
@ -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
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue