EPIC: Cross-repository specification reuse audit and canonical source-of-truth map #1666

Goal

Reduce implementation time by discovering, validating, and reusing existing T27 specifications, contracts, skills, tests, generators, and runtime components across the Trinity project family before creating new solutions.

Initial evidence to validate

• gHashTag/t27/specs/system/unified-agent-operations.t27 describes system layers, contracts, change folders, scheduler boundary, and evidence rules.
• gHashTag/t27/specs/queen/domains.t27 defines path-based domain routing and tests.
• gHashTag/t27/specs/queen/actors.t27 describes process identity, messaging, supervision, and explicitly distinguishes contracts from measured runtime behavior.
• gHashTag/t27/specs/claw/recipes.t27 records verified repair recipes and a fail-closed manual fallback.
• gHashTag/trinity/apps/website/public/t27/files/specs/queen/dispatch.t27 documents the task lifecycle and names the deployed supervisor and other adapters.
• gHashTag/trinity/apps/website/public/t27/files/specs/queen/control.t27 defines Queen control events and warns that some runtime behavior remains mirrored in the TypeScript supervisor.
• gHashTag/trinity/apps/website/public/t27/files/docs/agents/AGENTS_ALPHABET.md documents the 27-agent roster and responsibilities.
  These are starting points, not a claim that the full repository family has been audited.

Boundary

This is an evidence-gathering and reuse-planning epic. Do not create duplicate specifications or rewrite systems during discovery. Do not treat a spec as implemented merely because it exists. Separate canonical sources, generated mirrors, adapters, tested implementations, stale docs, and proposals.

User Scenarios & Testing

• Before a Bee designs a solution, it finds existing relevant specifications, code, tests, skills, examples, and issues.
• A reviewer can see which artifact is authoritative and which files are generated or mirrored.
• Two repositories that implement the same contract can be compared for parity and drift.
• Queen can route a task to a reusable implementation rather than asking a Bee to recreate it.

Work packages

1. Enumerate the relevant repository family and access status, including t27, trinity, BrowserOS, leela, and other directly referenced repositories.
2. Search and map T27 specs, runtime code, skills, tests, generators, CI workflows, issues, and operational dashboards.
3. For each capability, record canonical source, consumers, generated artifacts, mirrors, test evidence, drift risk, and owner/domain.
4. Identify duplicates and conflicting definitions; propose one canonical source and safe convergence path for each conflict.
5. Build a machine-readable reuse catalog and dependency graph; prefer T27 as the source of truth where the existing architecture supports it.
6. Validate important contracts against executable behavior and label each as spec-only, implemented, tested, deployed, or unknown.
7. Generate small, evidence-backed follow-up issues only after mapping dependencies and checking for duplicates.

Success Criteria

• Repository scope, access failures, and exclusions are explicit.
• Reuse catalog links exact paths, issues, tests, generated mirrors, and consumers.
• Every critical capability distinguishes specification from implementation and deployment evidence.
• Duplicate/conflicting artifacts have a proposed canonical owner and migration plan.
• A representative task demonstrates reuse discovery before solution generation.
• No implementation is recreated merely because its existing spec or code was not searched.
• Audit can be rerun and produces a stable, reviewable result.