Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

External Implementation Repo Sync Policy

Canonical reference for: Keeping design docs aligned with external implementation repos (cnc-formats, fixed-game-math, deterministic-rng, future Tier 2–3 crates).

Problem Statement

Design docs define capabilities for external standalone crates, but implementation proceeds in separate Git repositories by independent agents. Design divergence accumulates silently when capabilities are added to implementation repos without updating the corresponding design docs.

This policy codifies the sync points — what must trigger a design-doc update, where to update, and how to detect drift.

Sync Triggers

A design-doc update is required when any external implementation repo introduces:

Change TypeWhat to UpdateExample
New public function/type/traitD076 § Rust Typeslcw::compress(), VqaEncodeParams
New feature flagD076 § feature flag docs, Crate Design Principlescli, convert
New CLI subcommand or flagD076 § CLI subcommand roadmap--format flag, binary format conversions
Encoding/write capability05-FORMATS.md § Crate Goals, D076 § module tableSHP encoder, AUD encoder, VQA encoder
New format support05-FORMATS.md § format tablesAVI interchange format
Capability moved between crates05-FORMATS.md § crate splitEncoding in cnc-formats vs ic-cnc-content
New dependency addedD076 § Crate Design Principlespng, hound, gif, clap

Crate-to-Design-Doc Mapping

External CratePrimary Design DocsKey Sections
cnc-formatssrc/05-FORMATS.md, src/decisions/09a/D076-standalone-crates.md, src/formats/binary-codecs.mdFormat tables, Crate Goals, CLI roadmap, Rust Types, module allocation table
fixed-game-mathsrc/decisions/09a/D076-standalone-crates.md, research/fixed-point-math-design.mdTier 1 table, Rust Types
deterministic-rngsrc/decisions/09a/D076-standalone-crates.mdTier 1 table, Rust Types
Future Tier 2–3src/decisions/09a/D076-standalone-crates.mdRespective tier tables

Encoding/Write Capability Attribution Rules

The design docs historically assumed all encoding belonged in ic-cnc-content (GPL, Phase 6a, EA-derived). Implementation has shown that clean-room encoding is feasible in permissive crates. The attribution rule is:

  • cnc-formats (MIT/Apache-2.0): Clean-room encoders for all standard algorithms (LCW compression, IMA ADPCM encoding, VQ codebook generation, SHP frame assembly). These use publicly documented algorithms with no EA source code references. Sufficient for community tools, round-trip conversion, and Asset Studio basic functionality.
  • ic-cnc-content (GPL v3): EA-derived encoder enhancements that reference GPL source code for pixel-perfect original-game-format matching, plus encrypted .mix packing (Blowfish key derivation + SHA-1 body digest). Only needed when exact-match reproduction of original game file bytes is required.

When updating format table rows, annotate which crate provides read vs. write:

  • “Read: cnc-formats, Write: cnc-formats (clean-room) + ic-cnc-content (EA-enhanced)”

Drift Detection Workflow

When working on design docs that reference external crate capabilities:

  1. Before reinforcing a crate attribution, check the actual crate’s public API (GitHub source or crate docs). The design doc may be stale.
  2. When reviewing a design doc for accuracy, compare:
    • D076 § Rust Types against the crate’s actual pub items
    • D076 § feature flags against Cargo.toml [features]
    • D076 § CLI roadmap against the crate’s binary source
    • 05-FORMATS.md § Crate Goals against implemented capabilities
  3. When a gap is found, file an issue in this repo (label: documentation, cnc-formats or relevant crate name) cataloging the discrepancy.

Integration with Implementation Repo AGENTS.md

Each external crate’s AGENTS.md should include a reciprocal rule:

When adding new public APIs, feature flags, encoding capabilities, or CLI changes, check whether the design docs (especially D076 and 05-FORMATS.md) need updating. If they do, file an issue in the design-docs repo.

This creates a bidirectional sync obligation: design-docs agents check implementation repos before writing, and implementation-repo agents flag design-doc gaps when they create new capabilities.