# Fabric Autonomy Buildout Roadmap

This is the implementation tracker for turning Forge playbooks, physical capabilities, and agent
profiles into governed autonomous workflows. It complements the detailed operation checklist in
[`capability-buildout.md`](capability-buildout.md). Counts in prose are a 2026-08-20 baseline; the
live source of truth is:

```bash
venv/bin/python tools/fabric_autonomy_inventory.py --format markdown
```

The generated worklist is planning evidence only. It cannot execute, certify, publish, commission,
or mark a capability production-ready.

Checklist status is intentionally strict (inventory counts refreshed 2026-08-25):

- **Green (`[x]`)** means the named repository implementation is present and covered by focused
  verification. It does not imply that a containing release milestone is production-ready.
- **Amber (`[ ]`)** means real qualification, external review, activation, commissioning, or
  distribution evidence is still required. An audit harness is not a substitute for that evidence.

## Live baseline

- 143 physical Photoshop/Unity operations: 87 production-ready and 54 still gated; two unsafe,
  unbounded Unity proposals are explicitly retired and excluded from activation.
- 92 discovered skills across Forge and GOTM: 55 executable and 37 knowledge-only / awaiting
  reviewed activation contracts.
- The live scan now finds 13 GOTM-project skills. The original 12 project playbooks are indexed and
  have detached review candidates; the newly discovered `crown-war-blob-analyzer` is also
  knowledge-only and remains in the activation queue. None becomes executable until an adjacent
  reviewed `fabric_skill.json` declares a typed execution contract.
- Seven specialized domain-agent profiles now have persisted, disabled review drafts. They remain
  decommissioned and cannot run, certify, publish, or commission themselves; they are deliberately
  not one-agent-per-skill.
- Deterministic qualification and external-gate auditors are available, but they are fail-closed:
  they generate review packets and verify supplied evidence without contacting providers, enabling
  an agent, granting live control, or changing lifecycle state.
- The shared contract registry has 30 contracts and 3 compatibility deprecations. Context Envelope,
  shared-context binding, World State/replan, evidence-derived confidence, observer durability, and
  the Unity disposable-attestation feed boundary are repository-complete foundations; none grants
  production authority.
- The dedicated Faction Offers family is repository-implemented with exact per-faction source,
  artifact, review, spreadsheet, Git and Jira boundaries. The versioned 2D Iconic Item family is
  also repository-implemented; its exact Unity apply capability remains candidate-only until the
  approved disposable-project qualification closes.

## Cross-plane priority order

The authoritative responsibility map is
[`fabric-six-plane-authority-map.md`](fabric-six-plane-authority-map.md). Work converges existing
primitives into one contract spine; it does not create parallel stores or competing authorities.

1. **Keep one authority per state type.** Retire or make read-only any compatibility writer before
   adding consumers. Reconciliation always runs canonical-to-derived, never cache-to-authority.
2. **Build on the completed state spine.** Context Envelope, World State, evidence-derived
   confidence, and state-aware replanning precede performance optimization.
3. **Bind qualification to the environment.** Every qualification receipt must name the reviewed
   OS, Unity/Photoshop, model, runtime, provider, and contract revisions.
4. **Close Assurance gates.** Contract goldens/rejections, deterministic isolation tests,
   cross-plane emergency stop, deadline handling, and unknown-completion reconciliation remain
   mandatory at every effect boundary.
5. **Optimize last.** Provider/runtime KV and exact prompt-prefix caching are performance details.
   Do not add a semantic answer cache: stale generated answers cannot satisfy the freshness,
   provenance, workspace, authority, policy, and revalidation requirements of this architecture.

## Current repository and external gates

| Area | Repository-complete | Still external / operational |
|---|---|---|
| Context and state | Read-only digest-bound Context Envelope; World State and exact outcome-bound replan; evidence-derived confidence; exact expiring server-owned source verifier; the server-owned specialist-preview producer atomically registers and re-verifies its exact short-lived source, caller, workspace, and task bindings before assembly | Every future authoritative producer must use the same host-registration boundary before admission; caller self-assertions still fail `source_authority_unverified`; this repository wiring is not production qualification |
| RAG | Canonical-to-derived reconciliation metadata, fail-closed freshness checks, safe deletion/rebuild behavior; all seven workspaces completed a verified post-recommission refresh. Default was recommissioned at a clean Event Spine boundary; its prior signed chain is retained read-only under a checksum manifest, zero ambiguous Default facts were migrated, and all non-Default signed rows were preserved exactly. A later canonical change is expected to return an index to `canonical_revision_mismatch` until the next source freeze and refresh. | Reconcile only canonical-to-derived after source changes settle. Protected Google Sheets need OAuth/service access; the remaining Atlassian Cloud source needs access or an explicit retirement/replacement decision. Degraded collectors are never silently dropped. |
| Unity attestation | Read-only exact signed-feed resolver, Master-only job completion boundary, public-trust-only deployment seams, and exact job/receipt/candidate binding | A separately operated attestor, reviewed immutable feed, pinned identity/public key, approved disposable target, and one exact externally signed record per completed qualification job |
| Skills and physical capability | 92 skills inventoried; 55 executable; 37 activation-gated; deterministic review/qualification tooling; Faction Offers and the typed 2D Iconic Item procedure implemented | Owner-reviewed activation contracts; 2D Iconic Item Unity apply qualification; real accepted cases; independent review; certification/publication/commissioning |
| Distribution | Fail-closed audits and evidence projections | Signing, notarization, trusted installed builds, approved writable scopes, and production promotion |

## Version release-status audit

The wiki timeline uses green only for repository-recorded completed releases. Substantial code in an
amber milestone is still amber when its external release gate is open.

| Timeline milestone | Status | Reason |
|---|---|---|
| Foundations, v2.8, v2.10, v2.15, Grounded, v2.21, v3.0 | Green / shipped | Completed historical releases |
| v3.2 | Current release | Current governed local baseline |
| Fabric Core | Green / shipped | Governed advisory specialist layer is promoted and reversible |
| Engineering | Amber / building | Bug-fix engine is not yet live production service |
| v3.3, v3.4, v3.5, v3.6 | Amber / repository complete | Their named repository implementation scopes are closed; qualification, distribution, corpus, review, activation, or commissioning gates remain open |
| v3.7 | Amber / building | Faction Offers is repository-complete; 2D Iconic Item is implemented but its exact Unity apply capability still needs approved disposable-project qualification and later lifecycle gates |
| Next, Later | Planned | Future rollout and deeper-intelligence milestones |

## Upcoming features and qualification sequence

This is the ordered delivery queue after the repository foundations. Items are deliberately split
between product work and evidence that only an owner, independent operator, or infrastructure team
can supply.

### Now — operational trust closure

1. **RAG source-access completion.** Authorize the three protected Google Sheets through the
   existing OAuth reader, decide whether the remaining Atlassian Cloud page is retained, replaced,
   or retired, then run one incremental canonical-to-derived refresh after a source freeze.
2. **Independent Unity attestor onboarding.** Operate an Ed25519 signer outside Forge, mount its
   bounded regular-file feed read-only, and pin only
   `FORGE_UNITY_DISPOSABLE_ATTESTATION_FILE`,
   `FORGE_UNITY_DISPOSABLE_ATTESTOR_ID`, and
   `FORGE_UNITY_DISPOSABLE_ATTESTOR_PUBLIC_KEY` in Forge. The private key never enters this
   repository, process, request body, or deployment secret set.
3. **Source-authority adoption.** The specialist-preview host producer is integrated. Each future
   Context Envelope producer must register and re-verify its exact source, revision, digest,
   workspace, caller, task, and expiry through the same server-owned boundary before admission.

### Next — real capability qualification

1. **Qualification Operations view.** Present expiring attestor/feed health, selected capability and
   candidate digests, environment compatibility, accepted-case counts, independent-review state,
   and the next governed action without adding a signer or promotion button to Forge.
2. **Photoshop and Unity campaigns.** Qualify one exact capability family at a time against approved
   disposable targets, beginning with `unity.apply_iconic_item_2d_family`, then collect 20 distinct
   attributable accepted cases for the exact corpus
   being reviewed. A case cannot be copied across capability digests to inflate readiness.
3. **Evidence-led execution history.** Project verified Event Spine facts into operator-visible
   attempted/completed/uncertain/reconciled/compensated timelines. Unknown completion remains held
   for reconciliation; it is never presented as rollback or automatic retry.
4. **Checkpointed resume, after idempotency proof.** Resume only effect-free or explicitly
   reconciled DAG nodes from sealed checkpoints. Corrupt, cross-workspace, stale, or unknown
   checkpoints stay non-resumable.

### Then — hybrid and studio rollout

1. **Two-host runtime qualification.** Provision PostgreSQL as the sole hosted control authority,
   enroll two authenticated workers on distinct hosts, and retain signed baseline, failover,
   dead-letter, backpressure, and workspace-isolation evidence.
2. **Measured model intelligence.** Replace `unknown`/`unobserved` catalog fields only with retained
   latency, cost, cache, privacy, structured-output, and tool-call measurements bound to the exact
   model/provider/runtime/environment revisions.
3. **Signed distribution.** Build with an approved Developer ID identity, submit to Apple notary,
   retain the accepted receipt, verify stapling and Gatekeeper, and obtain Security/SRE approval.
4. **Vertical commissioning.** Commission the first Production, QA, Product, and Art agents only
   after their exact skills, capabilities, models, permissions, qualification evidence, publication,
   and human owner approvals are bound.

### Later — deeper intelligence

- Expand Code Intelligence into review, validation planning, feature planning, and impact analysis.
- Expand the Production Knowledge Graph beyond character workflows while keeping it a read-only
  projection over existing authorities.
- Add policy-gated team inference and cloud burst only after measured model cards and tenant
  isolation pass qualification.
- Add cross-team memory and knowledge federation with explicit workspace/game scope, provenance,
  retention, and revocation. No semantic answer cache is planned.

## Delivery checklist

### Phase 0 — truthful inventory and composition

- [x] Use the physical capability manifest as the operation source of truth.
- [x] Keep knowledge-only and executable skills visibly separate.
- [x] Generate a current Claude/Toolsmith capability queue from live manifests.
- [x] Generate a skill-activation queue from live skill contracts.
- [x] Add specialized profiles for Photoshop, Unity, GOTM character production, simulator/testing,
  merge integration, feature configuration, and Toolsmith capability building.
- [x] Expose the generated activation queues in Capability Center without adding activation authority.

### Phase 1 — activate GOTM project playbooks safely

- [x] Add a non-authorizing typed-activation readiness check requiring declared inputs, outputs,
  effects, completion evidence, and validation capabilities. Existing legacy contracts remain
  backward compatible, but a GOTM contract stays in the activation queue until this check passes.
- [x] Audit all 12 GOTM `SKILL.md` files and generate detached review candidates with typed inputs,
  outputs, effects, validators, task signals, required capabilities, and deterministic digests.
  These packets are planning artifacts only and do not modify the GOTM repository.
- [ ] Add adjacent `fabric_skill.json` contracts in the GOTM repository only after project-owner
  review. A contract opts into governed execution; it does not itself supply an executor.
- [x] Keep every unsupported candidate step `MANUAL` or `UNRESOLVED`; never claim AUTO from prose.
- [x] Validate the detached candidate catalog and its exact pilot/exclusion policies. Repeat the
  validation and task-selection suite after owner-approved contracts are activated.
- [ ] Promote only the first high-value families: character setup/tuning/ProtoData, simulator, merge,
  and EOS/feature configuration.

Activation order from the project-playbook audit:

1. **Low-risk pilots:** `gotm-simulator` in scorecard-only/no-`SaveProto` mode;
   `feature-unlock-setup` as reviewed isolated-worktree diffs; and `eos-development-admin` with
   development `get` only.
2. **Deterministic data preparation:** `eos-experiment-setup`,
   `generate-proto-data-overrides`, and `summon-pack-setup`, after typed ProtoData, serializer,
   localization, CSV, and Unity-meta adapters exist.
3. **Complex implementation and tuning:** `character-ability-setup`,
   `character-tuning-workflow`, and `bugsnag-jira-fix-workflow`, with bounded test runners,
   cancellation, exact evidence, and branch-local writes.
4. **Outward source control:** `gotm-forward-merge` and `gotm-back-merge` remain assisted until a
   typed Git merge/PR executor, isolated worktree ownership, conflict stop, and remote readback are
   qualified. Fabric's DAG `merge` capability is not a Git merge operation.
5. **Grounding only:** `gotm-gameplay-developer` remains knowledge-only because it is a context map,
   not a bounded workflow with a terminal output and acceptance contract.

### Phase 2 — instantiate and qualify specialized agents

- [x] Create one disabled, decommissioned review draft from each of the seven domain profiles.
- [x] Add a read-only commissioning audit that verifies Forge provenance, the review-only boundary,
  disabled routing, a typed workflow, pinned executable skills, and the exact approved release.
  The live drafts still fail the workflow/skill/release gates and remain decommissioned.
- [x] Bind only installed executable skills at run start; keep RAG-only playbooks as grounding.
  The execution copy resolves a fresh bounded `skill_manifest` on every run, seals its digest, and
  excludes knowledge-only contracts even when a domain profile recommends them.
- [x] Validate tool readiness separately from profile selection. Profile resolution remains a
  recommendation boundary; exact tool receipts and commissioning readiness are evaluated by
  separate fail-closed projections and never inferred from a selected profile or installed skill.
- [ ] Certify each agent on a representative accepted-ticket corpus before publication.
- [ ] Publish and commission exact revisions separately; profile availability grants no authority.

### Phase 3 — close the physical capability queue

- [x] Generate deterministic, disabled review batches from the live physical and skill-activation
  queues. Unresolved types, fixtures, graph bindings, validators, and approvals remain explicit;
  the batcher cannot invoke qualification or activation.
- [ ] Qualify the registered Photoshop UXP candidates in disposable working documents.
- [ ] Implement missing typed handlers before qualification where the live report says `missing`.
- [x] Retire the unbounded Unity menu-allowlist and arbitrary custom-editor-extension proposals;
  neither can silently return to resolution or activation.
- [x] Implement and register the distinct non-qualification, disposable-only runtime contract for
  `unity.set_texture_importer_settings`; handler existence remains separate from qualification and
  production authority.
- [ ] Qualify `unity.batch_execute` with exact per-command evidence and independently attest the
  TextureImporter disposable runtime. Qualification-only dispatch is not runtime authority.
- [ ] Preserve the lifecycle `draft → validated → sandbox verified → candidate → certified → pilot → production`.
- [ ] Require the accepted 20-case corpus, independent review, and explicit promotion before
  `production_ready=true`; one sandbox success proves viability only.

### Phase 4 — exact demonstration capture

- [x] Retain universal application/focus observations without raw keys, clipboard data, screenshots,
  or pointer coordinates.
- [x] Add typed prospective capture for the current Photoshop and Unity allowlists.
- [x] Add the explicit evidence-quality lattice and replay-sufficiency gate: exact provider-verified
  evidence is distinct from typed-but-unattested provider observation, consented visual evidence,
  Accessibility context, and unobserved gaps.
- [x] Expand prospective capture for detailed supported Photoshop layer/transform/guide/export
  operations and Unity component/GameObject/ScriptableObject/sprite/TextureImporter operations.
  Unsupported fields, native-integrity failures, and readback mismatches remain explicit gaps.
- [x] Add vision only as separately consented, encrypted, review-only evidence and target
  disambiguation. It cannot manufacture provider targets/arguments or become actuation authority.
- [x] Add signed Finder/browser/spreadsheet native-operation contracts and server source seams that
  degrade without stopping the recording.
- [ ] Install and trust a signed Photoshop native challenge/hybrid add-on in the real application;
  repository challenge/envelope support is not installed-build proof.
- [ ] Build, sign, install, key, manifest, and qualify the Finder/browser/spreadsheet/Numbers native
  transports. Until then their exact source seams remain observation-only and replay-blocked.

### Phase 5 — Learning Studio to Toolsmith and Forge Studio

- [x] Save/load recordings, human semantic review, include/exclude decisions, capability analysis,
  progress/cancellation/deadlines, exact gap handoff, and review-only Studio candidate registration.
- [x] Keep source-control readiness checks separate from demonstrated user steps.
- [x] Enforce durable cross-process live-control ownership with consent, visible overlay, and stop.
- [x] Add Capability Center bulk triage for related gaps without weakening exact gap identities.
  Evidence-only gaps yield bounded recapture plans; they never become Toolsmith build jobs.
- [x] Add bounded, cancellable/deadline-aware qualified-selection reanalysis services that resolve
  the Task Workspace and exact selected capability server-side.
- [x] Link Capability Center's authoritative exact qualified-capability selection receipt into the
  reanalysis UI. The operator explicitly chooses one server-resolved capability for one retained
  gap; the server rebinds its digests before issuing the review-only link and Learning Studio starts
  only from that receipt. A completed Toolsmith job alone never triggers or chooses a capability.

### Phase 6 — governed sandbox execution

- [x] Add a read-only exact-replay gate audit for sealed plan/validation/review linkage, commissioned
  graph drift, provider bindings, disposable-sandbox attestation, and rollback evidence. It never
  acquires fresh consent or execution authority.
- [x] Add server-owned, bounded sandbox preparation for exact plan binding, protected/game-target
  rejection, disposable target description, cancellation/deadlines, idempotency, and sealed
  no-write validation. The preparation projection cannot attest an external sandbox.
- [ ] Bind every included semantic action to an exact commissioned Skill Graph capability.
- [ ] Supply an authoritative disposable-sandbox attestation for a positively identified
  Photoshop/Unity/project target.
- [ ] Validate the sealed plan without writes, then obtain separate one-run live-control consent.
- [ ] Execute deterministic application operations with postcondition evidence and rollback.
- [x] Never replay historical focus-only recordings as if exact edits had been captured. Context-only
  focus/selection observations cannot be included as replay steps, and provider-write validation
  requires exact provider-verified typed targets, arguments, and postconditions.

### Phase 7 — release and operational evidence

- [x] Add a digest-sealed, fail-closed release-evidence projection that separates repository
  implementation from external qualification, distribution, corpus, review, and commissioning
  gates. It reports packet completeness only, always returns `production_ready=false`, and requires
  a separate authoritative release service to verify signed sources and change lifecycle.
- [x] Emit deterministic corpus identity and accepted-case IDs, and fail closed unless 20 distinct
  accepted attributable cases plus an independent review bound to that exact corpus are supplied.
- [x] Add a read-only macOS release audit for archive/receipt identity, package verification,
  Developer ID signature, accepted notarization, stapling, and Gatekeeper assessment. It cannot
  build, sign, submit, staple, authorize, or distribute anything.
- [ ] Package, sign, and notarize the desktop observer and app adapters.
- [ ] Install and independently verify trusted build keys and native capture products, including the
  Photoshop native challenge/hybrid add-on and cross-app transports.
- [ ] Run at least 20 distinct accepted cross-application production cases.
- [ ] Obtain an identified independent review of the sealed 20-case corpus.
- [ ] Measure step-to-capability binding, validation success, human correction, rollback, latency,
  and capability-gap recurrence.
- [ ] Mark roadmap versions green only when their external release gates have real evidence.

## Operator qualification and release checklist

These commands are read-only with respect to Fabric authority and application providers. The
qualification command writes an inert JSON review packet only when `--output` is supplied. The
release audit
returns exit code `2` while evidence is missing or invalid; that blocked result is expected until a
real signed and notarized distribution exists.

1. Snapshot the live implementation inventory:

   ```bash
   venv/bin/python tools/fabric_autonomy_inventory.py --format markdown
   ```

2. Generate deterministic, disabled qualification batches for Toolsmith and project-owner review:

   ```bash
   venv/bin/python tools/fabric_qualification_batches.py \
     --output /tmp/fabric-autonomy-qualification-batches.json
   ```

   Review every `blocking_reasons` entry. Do not treat packet validation as no-write qualification,
   sandbox smoke, activation, certification, or production evidence.

3. Collect only real evidence: exact disposable fixtures and sealed graphs for capability work;
   owner-approved adjacent contracts for project skills; representative accepted-ticket results for
   specialist agents; and distinct attributable production cases with identified human acceptance.

4. Run the focused deterministic audit suite before presenting a gate packet:

   ```bash
   PYTHONDONTWRITEBYTECODE=1 PYTHONPATH=tests:dashboard \
     venv/bin/python -m pytest -q \
     tests/test_autonomy_qualification_batches.py \
     tests/test_autonomy_external_gate_audit.py \
     tests/test_physical_production_readiness.py \
     tests/test_autonomy_release_evidence.py \
     tests/test_audit_macos_release.py
   ```

5. After an approved build/sign/notarize process has produced real artifacts, verify them without
   mutating them:

   ```bash
   venv/bin/python tools/audit_macos_release.py \
     --archive /absolute/path/to/Forge-macOS.zip \
     --receipt /absolute/path/to/notarization-receipt.json \
     --app /absolute/path/to/Forge.app
   ```

6. Review the exact remaining blockers in
   [`fabric-autonomy-external-gates.md`](fabric-autonomy-external-gates.md). Request activation,
   promotion, commissioning, live control, or distribution only through their separate governed
   services after the corresponding real evidence exists.

## Recommended ownership

- Claude: execute the generated physical capability queue, implement/qualify Photoshop and Unity
  handlers, and author candidate GOTM contracts for human review.
- Toolsmith: validate contracts, run disposable sandbox qualification, retain evidence, and propose
  lifecycle transitions.
- Fabric Core/domain agents: plan and analyze advisory work only until exact executable contracts and
  commissions exist.
- Human owners: approve project skill activation, capability promotion, agent publication,
  commissioning, live control, and outward source-control changes.