133 lines
5.7 KiB
Markdown
133 lines
5.7 KiB
Markdown
# 6. WALKING_SKELETON_SPEC.md
|
|
|
|
## 6.1 Goal
|
|
|
|
Prove the Foundation through a small set of end-to-end semantic properties before broad implementation. Do not build all future modules/stubs first.
|
|
|
|
## 6.2 Skeleton topology
|
|
|
|
Initial process topology:
|
|
|
|
```text
|
|
Client/Test Harness
|
|
|
|
|
Core Runtime
|
|
- Identity
|
|
- Situation
|
|
- Work
|
|
- Epistemics (minimal)
|
|
- Capability registry (minimal)
|
|
|
|
|
+---- Cognitive Worker Adapter (deterministic fake first, real model later)
|
|
|
|
|
+---- Continuity Runtime ---- Temporal adapter (optional/replaceable)
|
|
|
|
|
+---- Commit Runtime (separate process, isolated credentials)
|
|
|
|
|
Test Executor
|
|
```
|
|
|
|
One PostgreSQL cluster, separate owner schemas/roles. NATS may be used for integration events once owner-local outbox exists; skeleton must also prove semantics do not live only in NATS.
|
|
|
|
## 6.3 Scenario WS-001 — Focus Isolation / wrong-project prevention
|
|
|
|
**Given** one Actor has two simultaneously active Codex/workspace situations bound to Project/Goal contexts A and B. Both domains contain an identically named concept such as `temperature`.
|
|
|
|
**When** the identical user phrase is sent through each session without naming the project.
|
|
|
|
**Then** Situation resolution binds each request to its own session/workspace/project context using runtime bindings/provenance; no keyword shortcut is allowed; canonical writes carry target/revision/scope and cannot affect the other context.
|
|
|
|
Required failure cases:
|
|
- stale focus binding;
|
|
- two worktrees of same repository;
|
|
- ambiguous target → typed ambiguity, no mutation;
|
|
- Task revision changed between reasoning and commit → commit rejected/re-evaluated.
|
|
|
|
Acceptance property: **wrong-project mutation is mechanically prevented even if cognition proposes the wrong target**.
|
|
|
|
## 6.4 Scenario WS-002 — Durable prospective memory independent of Temporal
|
|
|
|
**Given** user creates a future reminder/commitment with semantic context and fulfilment condition.
|
|
|
|
**When** canonical Continuity transaction commits, process restarts, Temporal state is deleted/unavailable, then workflow infrastructure is rebuilt.
|
|
|
|
**Then** obligation remains in PostgreSQL canonical prospective state, is reconstructed, does not duplicate occurrence, revalidates relevance before delivery, and can distinguish `DELIVERED` from underlying `FULFILLED`.
|
|
|
|
Failure cases:
|
|
- system offline past trigger;
|
|
- 100 duplicate trigger messages;
|
|
- goal superseded before trigger;
|
|
- delivery channel unavailable;
|
|
- recurrence missed during outage.
|
|
|
|
Acceptance property: **loss of workflow engine does not lose or blindly replay future obligations**.
|
|
|
|
## 6.5 Scenario WS-003 — Safe Action Commit and unknown outcome
|
|
|
|
**Given** cognition produces a structured external mutation proposal.
|
|
|
|
**When** Commit Runtime receives it.
|
|
|
|
**Then** it validates current Authority, Scope, Target identity, task/goal justification and relevant revisions before producing AuthorizedAction. Only isolated Executor has external mutation credentials.
|
|
|
|
Injected case: executor applies external effect but connection times out before acknowledgement.
|
|
|
|
Expected result: `UNKNOWN_OUTCOME`; no blind retry; reconciliation query/verification required. A retry uses same ActionIntentID and a new AttemptID only after semantics permit.
|
|
|
|
Acceptance property: **no external side effect can bypass authority/commit and timeout cannot cause duplicate mutation by default**.
|
|
|
|
## 6.6 Scenario WS-004 — Topology equivalence
|
|
|
|
Run WS-001/002/003 twice:
|
|
|
|
1. bounded modules co-located where allowed;
|
|
2. Commit and Continuity accessed through remote adapters/processes.
|
|
|
|
Canonical semantic outcomes/invariants must be equivalent. Timing and expected temporary unavailability may differ; domain meaning must not.
|
|
|
|
Acceptance property: **process extraction does not require domain rewrite**.
|
|
|
|
## 6.7 Scenario WS-005 — No-LLM degraded continuity
|
|
|
|
Remove all cognitive providers.
|
|
|
|
System must still:
|
|
- identify existing actors/sessions where deterministically available;
|
|
- preserve events/state;
|
|
- keep canonical commitments/prospective schedules;
|
|
- perform deterministic authority/integrity checks;
|
|
- expose degraded capability state;
|
|
- avoid inventing new AI decisions/actions.
|
|
|
|
Acceptance property: **loss of cognition degrades intelligence, not continuity/integrity**.
|
|
|
|
## 6.8 Scenario WS-006 — Semantic evolution drill
|
|
|
|
Create a deliberately small v1→v2 contract/schema change in a non-critical skeleton concept. Prove:
|
|
|
|
- old historical object remains interpretable;
|
|
- new writer/readers use new version;
|
|
- unsupported semantics are explicit, not silently defaulted;
|
|
- active live objects migrate/validate;
|
|
- derived projections rebuild;
|
|
- rollback/forward-fix mode is documented.
|
|
|
|
Acceptance property: **architecture evolution is tested as a transformation, not merely promised**.
|
|
|
|
## 6.9 Foundation Exit Criteria
|
|
|
|
Foundation V1 is eligible for freeze when all are true:
|
|
|
|
1. Fresh Codex session can implement a bounded feature from repository artifacts alone.
|
|
2. Cross-owner DB write is physically denied.
|
|
3. Wrong-project mutation fails even under adversarial cognition proposal.
|
|
4. Stale/revoked authority cannot create AuthorizedAction.
|
|
5. Duplicate/replay does not duplicate external side effects in covered semantics.
|
|
6. Future obligation survives workflow-engine loss/rebuild.
|
|
7. Core remains continuity-capable without any LLM.
|
|
8. Same semantic scenarios pass in at least two process topologies.
|
|
9. Provider can be swapped/faked without domain contract change.
|
|
10. Declared and observed architecture graphs match or all drift has registered findings.
|
|
11. One semantic contract migration drill succeeds.
|
|
12. Architecture guardrail suite proves its own critical enforcement with negative tests.
|