Assistant/architecture/WALKING_SKELETON_SPEC.md

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:

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.