Skip to content

arch: replace hardcoded STATE_DIRS/STATE_FILES in externalize.ts with discoverable manifest #863

Closed

Description

@diberry

Problem

Current state: externalize.ts contains hardcoded lists of state directories and files. When new state artifacts are added to the project later, they will be silently orphaned during state externalization.

Root cause: No discoverable mechanism for state managers to register their artifacts. Any changes to state structure require manual updates to externalize.ts.

Issues

  1. Silent data loss risk: New state artifacts added after deployment won't be included in externalization
  2. No transactional safety: If externalize fails mid-copy, state ends up split between old and new locations
  3. Operator blind spot: No audit trail or validation that all state was migrated

Proposed solution

  • Discoverable manifest: State managers register artifacts in a discoverable way (e.g., package manifest, registry file, or module exports)
  • Copy-verify-delete pattern: Atomic externalization with verification before cleanup
  • Rollback mechanism: Transactional guarantee or clear recovery steps if externalize fails mid-operation

Success criteria

  • No state artifacts are orphaned when new artifacts are added
  • Externalize operation is atomic or has clear rollback
  • Operators have visibility into state migration success/failure

Activity

  1. diberry commented on Apr 6, 2026

    @diberry
    ContributorAuthor

    ✈️ Flight — Issue-Level PRD

    Summary

    externalize.ts hardcodes STATE_DIRS and STATE_FILES arrays that must be manually updated whenever new state artifacts are added. This creates silent data loss risk during externalization. This PRD replaces the hardcoded lists with a discoverable manifest that state managers register into, plus atomic copy-verify-delete operations.

    Problem Statement

    • New state artifacts added after deployment are silently orphaned during externalization
    • No mechanism for state managers to register their artifacts
    • If externalization fails mid-copy, state ends up split between old and new locations
    • No audit trail or validation that all state was migrated successfully

    Proposed Approach

    Phase 1 — State Artifact Registry (P0)

    • Define a StateArtifact interface: { path: string, type: 'dir' | 'file', owner: string, critical: boolean }
    • Each state manager exports a getArtifacts(): StateArtifact[] function
    • externalize.ts discovers artifacts by calling each manager's getArtifacts() instead of reading hardcoded arrays
    • CI test: compare discovered artifacts vs actual .squad/ contents — fail if any unregistered artifacts exist

    Phase 2 — Atomic Externalization (P1)

    • Replace current copy-in-place with copy-verify-delete pattern
    • Copy all artifacts to new location, verify checksums/existence, then delete originals
    • On verification failure: rollback (delete copies, preserve originals), surface error
    • Add --force flag to skip verification for emergency recovery

    Phase 3 — Operator Visibility (P2)

    • squad doctor reports registered vs actual state artifacts
    • Externalization produces a migration manifest (JSON log of what moved where)
    • Rollback instructions included in error output

    Acceptance Criteria

    • STATE_DIRS and STATE_FILES hardcoded arrays removed from externalize.ts
    • State managers register artifacts via getArtifacts() interface
    • CI test catches unregistered state artifacts
    • Externalization uses copy-verify-delete pattern
    • Verification failure triggers rollback with clear error message
    • squad doctor reports state artifact registration completeness
    • Migration manifest (JSON) produced on each externalization

    Architecture Notes

  2. added 5 commits that reference this issue on Apr 7, 2026
    cbac697
    bc9d88e
    b9a3bc2
    93c6be3
    a01fd71
  3. diberry commented on Apr 10, 2026

    @diberry
    ContributorAuthor

    🔒 On hold — high-touch architecture work (PR #908 exists but blocked on SDK republish).

  4. added a commit that references this issue on Apr 12, 2026
    f50bbc8
  5. added a commit that references this issue on Apr 21, 2026
    ae46701
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or improvement

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions