page:docs-specs-platform-gaps-00-intent
Platform Gaps & t3code Migration — Intent and Decisions reference
Date: 2026-09-27 · Decision source: interactive interview with Tal (run owner) · Status: BINDING for this spec effort
Platform Gaps & t3code Migration — Intent and Decisions
Date: 2026-09-27 · Decision source: interactive interview with Tal (run owner) · Status: BINDING for this spec effort
Mission
Research, then thoroughly spec (no implementation yet) what is missing in the fabric repo for:
1. **Functionality coverage** of the holistic platform (what the platform claims/needs vs what is wired and working). 2. **Testing** of the holistic platform (not per-package only — the platform as one product). 3. **Packaging fabric as a platform** (an installable, distributable product). 4. **Migration from t3code** (https://github.com/pingdotgg/t3code): replace/adapt fabric's own versions of the harness control surface — **especially the interfaces** — in adapters and kradle, using t3code's implementations. 5. **Private isolation & rename** (amendment 2026-09-27b): the public babysitter repo remains open, maintained, and publishing npm under the old names, exactly as today; the fabric repo becomes the **isolated private product** — components/packages renamed to neutral names under a new scope, privately distributed, free to diverge in implementation.
Every gap becomes a numbered, implementation-ready **work package** with acceptance criteria, affected paths, test requirements, and dependencies — directly executable by later babysitter implementation runs.
Binding decisions (from interview, 2026-09-27)
| # | Topic | Decision |
|---|---|---|
| D1 | Adoption model | **The spec decides per component** (vendor-wholesale vs extract-packages vs implement-contracts), with explicit tradeoffs; approved at Gate A. |
| D2 | Replacement scope | ALL FOUR surfaces in scope: (a) adapters harness-driving layer, (b) kradle control-surface interfaces, (c) genty client shells (retired in favor of adapted t3code apps), (d) remote-access stack (ssh/tailscale/cloud relay). |
| D3 | Packaging forms | **All three**: single-node installer UX (curl\ |
| D4 | Deliverable | Work-package-ready specs under fabric/docs/specs/platform-gaps/. **No implementation in this run.** |
| D5 | Effect-TS | t3code is Effect-TS throughout; fabric is plain TS. **Spec decides per package**: quarantine-behind-boundaries vs adopt vs de-Effect, with explicit boundary rules where Effect may not leak. |
| D6 | Protocol | **ACP (Agent Client Protocol) becomes fabric's CANONICAL harness protocol** in adapters. The current adapters event model becomes an internal projection/derived view. |
| D7 | Testing bar | (a) **Live per-harness e2e matrix** — Claude Code, Codex, Cursor, Grok Build, OpenCode, Antigravity; (b) **whole-platform e2e** — packaged install → create run → dispatch → agent session → journal → UI assertions; (c) **unit floors + CI gating** — every package's suite wired into CI with agreed floors. (Adversarial correctness suite is NOT part of the bar but may be recommended.) |
| D8 | Prior audit | **Refresh the 2026-09-14 audit** (findings register: C:/work/company/products/platform/PLATFORM-REMEDIATION-AND-RENAME-ROADMAP.md, Appendix A). Re-verify which findings still hold after the GKE-migration churn; absorb the survivors into the coverage spec. |
| D9 | Fork posture | **Per-package**: spec proposes (e.g.) tracked-fork for protocol-churny units like contracts/effect-acp, hard-fork for the apps. |
| D10 | API breakage | **Break freely, major bump.** No compatibility shims. In-repo consumers migrated in the same effort. |
| D11 | Priorities | Top-2 sequenced FIRST: **(1) t3code interface migration, (2) functionality coverage gaps.** Testing infrastructure and packaging follow in the roadmap. |
| D12 | Guaranteed gap | **Hosted remote access** (a cloud-relay story à la app.t3.codes plus ssh/tailscale) MUST appear in the coverage spec regardless of research findings. |
| D13 | Mobile | **Deferred.** Mobile (iOS/Android) noted as future work; spec depth on server/web/desktop only. |
| D14 | Naming (amended by D17–D21) | Public-facing product renaming/branding remains OUT of scope. Specs REFER to components by current names (adapters, kradle, genty, babysitter(-sdk), kip-sdk, atlas, trust-core, observer, commander) but the PRIVATE package/component rename inside fabric is IN scope per D17–D21. |
| D15 | License | t3code is **MIT (T3 Tools Inc., 2026)** — adoption is legally clean; specs must include attribution/third-party-license work items. |
| D16 | Review gates | Exactly two user gates: **Gate A** after research synthesis + adoption-model proposal; **Gate B** over the final spec set. |
Amendment 2026-09-27b (post-Gate-A, interview round 5) — private isolation & rename
| # | Topic | Decision |
|---|---|---|
| D17 | Two-repo model | The public a5c-ai/babysitter repo stays open, maintained, and **keeps publishing npm under the old @a5c-ai/* names** — untouched by this effort. Fabric is the private product. **Hard split NOW**: mirroring stops; the t3code migration and ALL new work land fabric-only; upstream public fixes flow only by opportunistic cherry-pick. |
| D18 | Private names | **Neutral/descriptive names** (no mythology): e.g. orchestrator(-sdk), control-plane, agent-runtime, memory, catalog, harness-gateway, model-gateway, trust, console, operator, process-library, packages — the rename spec proposes the complete mapping matrix; final lock at Gate B. |
| D19 | Private distribution | **GCP Artifact Registry npm** in the existing GCP project (WIF auth already in CI). New npm scope proposed by the rename spec. Publishing renamed packages to the PUBLIC npm registry is forbidden; isolation guards required. |
| D20 | Rename surface | **Full surface, phased**: npm packages + binaries + env vars + directories + code identifiers + chart/CRD names. Absorb docs/adapters/terminology-and-structure-gaps/* and docs/blueprints-rename/. Phase order: packages + binaries first, the rest in later phases. |
| D21 | Spec integration | New spec 15-private-isolation-rename.md (WP-RN-\*), authored BEFORE 10-t3code-migration.md finalization so migration work packages land units under the NEW private names/scope. Specs 10/20/30/40/50 must be consistent with it (private registry in packaging, CI/publish isolation from public pipelines, no WP may alter the public repo). |
Repos and fixed paths
- fabric repo:
C:/work/fabric(npm workspaces monorepo; packages: adapters, atlas, babysitter, babysitter-sdk, genty, kip-sdk, kradle, observer-dashboard, trust-core; apps/commander). - t3code snapshot (MIT, cloned 2026-09-27, shallow):
C:/Users/tmusk/AppData/Local/Temp/claude/C--work-company/368e0399-fd11-4960-8b4d-b4dcf1d79c43/scratchpad/t3code— pnpm monorepo:apps/{server,web,desktop,mobile,marketing},packages/{contracts,effect-acp,effect-codex-app-server,client-runtime,shared,ssh,tailscale},native/*,packaging/, install script machinery. - Prior findings register:
C:/work/company/products/platform/PLATFORM-REMEDIATION-AND-RENAME-ROADMAP.md(Appendix A: C1..C3, H1..H10, M1..M8, S1..S6, CAP1..CAP6, KIP-TODO, TEST1..2, HYG1..4). - Pre-existing fabric gap docs to reuse/absorb, not duplicate:
docs/agent-layer-gaps.md,docs/atlas-library-gaps.md(and any others Phase 0 finds).
Acceptance criteria for the WHOLE run
1. docs/specs/platform-gaps/ contains: 00-intent.md (this file), research dossiers, and specs 10-t3code-migration.md, 15-private-isolation-rename.md, 20-functionality-coverage.md, 30-testing.md, 40-packaging.md, 50-roadmap-workpackages.md. 2. Every decision D1–D16 above is visibly honored in the specs (Gate-B verification compares specs against this file verbatim). 3. Every gap is a numbered work package: ID, objective, affected paths, acceptance criteria, test requirements, dependencies, size estimate (S/M/L). 4. The t3code migration spec covers, per migrated unit: adoption model, Effect stance, fork posture, license/attribution, and the ACP-canonical adapters re-platforming. 5. No placeholder text (TBD/TODO/fill-in) anywhere in the delivered specs. 6. User approved Gate A and Gate B; specs committed in fabric on a dedicated branch. 7. Two-repo invariants (D17/D19): no work package alters the public babysitter repo's names or publishing; the rename spec includes guards preventing accidental publication of renamed packages to public npm; migration WPs land units under the private names per the rename spec. 8. Quality bar (amendment 2026-09-27c): the spec set converged through **adversarial scored review to ≥ 90/100** (≤4 rounds) on weighted criteria — decision-fidelity 20%, evidence-grounding 15%, WP-implementability 20%, completeness 15%, cross-spec-consistency 10%, testing-rigor 10%, risk-and-sequencing-realism 10% — where 90+ means an implementation agent could start with no clarifying questions on any work package.