Skip to content

meta(fork-sync): hardening architecture epic — prevent #2408-class regressions #2433

@alexey-pelykh

Description

@alexey-pelykh

Problem

RemoteClaw has experienced a recurring class of fork-sync regression where:

  1. Upstream sync re-introduces a previously-gutted file as a stub (unconditional throw, no-op return, or constant-false handler)
  2. Production callers exist
  3. All call-site tests mock the function, returning what the non-stub version would return
  4. CI passes (mocks "work")
  5. Production crashes user-visibly on every dispatch

Documented instances:

Three sync events (#2298, #2360) shipped this class. Manual review and acceptance-criteria unit tests have not been sufficient at fork-sync scale (sync PRs touch 700-2,500 commits).

Architecture decision

Per /suggest + /evaluate analysis on 2026-04-19:

  • The actual lever is mock/real divergence detection, not "more tests"
  • The strongest interventions are CI gates / lint rules / declarative attestation, not new test files
  • Sequenced rollout in 3 phases over ~8 weeks

Phase 0 — Foundational

Phase 1 — NOW (within 2 weeks of #2408 fix)

Phase 2 — within 6 weeks

Phase 3 — within 8 weeks

Deferred (with revisit triggers in child issues)

Success criteria

Dependency graph

#2434 (ADR) ─┬─> #2435 (AST gate) ─────┐
             ├─> #2436 (baselines) ────┼──> #2441 (composite gate)
             └─> #2437 (attestation) ──┘

Deferred items (#2438, #2439, #2440) are tracked under this epic but not on the active path.

References

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions