Activity

1. diberry commented on Apr 2, 2026

   

   diberry

   on Apr 2, 2026

   ContributorAuthor

   More actions

   @copilot Please review this issue PRD. Focus on: Is the JSON schema complete? Are the utility function signatures right? Any concerns about the generator approach (parsing routing.md Markdown + extracting TEMPLATE_MANIFEST from TypeScript)? Is there a simpler way to achieve the same goal?
2. diberry commented on Apr 2, 2026

   

   diberry

   on Apr 2, 2026

   ContributorAuthor

   More actions

   Architecture Review: Issue #736 — Repo Registry

   Executive Summary

   The registry design is sound and well-motivated. It elegantly bridges three data sources (routing.md, templates.ts, package.json) into a consumable JSON layer that unlocks #670 and #733. The schema is complete, the approach is proven, and the few concerns below are minor and easily addressed.

   ---

   1. ✅ JSON Schema: Correct & Complete

   Assessment: The schema is well-structured. Minor observations:

   Recommendations:

   • *Add \metadata.source_hash* (recommended): Include a content hash of source files (routing.md, templates.ts, package.json) in the registry metadata. This enables deterministic rebuilds and helps CI detect which files triggered a re-generation:
     \\jsonc
     {
     "generated": "ISO 8601 timestamp",
     "generator": "scripts/generate-repo-registry.mjs",
     "metadata": {
     "routing_md_hash": "sha256:abc123...",
     "templates_ts_hash": "sha256:def456...",
     "package_json_hash": "sha256:ghi789..."
     }
     }
     \\

   • *\modules[].deprecated* (optional but future-proof): Consider adding a \deprecated\ flag for modules that are being sunset. This doesn't break PRD: Versioned file layout manifest - single source of truth for directory structure #670/feat: PR architectural impact analysis — blast radius, module boundaries, reviewer routing #733 but gives them future flexibility.

   • Schema should be validated: Add a TypeScript interface in scripts/registry-utils.mjs with Zod or similar (if the team uses runtime schema validation elsewhere). This prevents silent corruptions if the generator produces invalid JSON.

   ---

   2. ✅ Location: \scripts/\ is Correct

   Assessment: Using \scripts/\ for build-time generators is the right call.

   • Mirrors existing patterns: \sync-templates.mjs, \�ump-build.mjs, \generate-api-docs.mjs\ already live here. Consistency is good.
   • Lifecycle: These are pre-build utilities, not runtime code. \scripts/\ is the home.
   • Commit output (.squad/repo-registry.json) is also appropriate — it's repo metadata, not user config.

   ✅ No changes needed.

   ---

   3. ⚠️ Parsing routing.md: Risk is Manageable

   Assessment: Regex parsing of Markdown tables is inherently fragile, but the risk is contained and testable.

   Observed Structure in routing.md:

   \\

   Module	Primary	Secondary
   \src/adapter/\	EECOM 🔧	CAPCOM 🕵️
   \\

   Concerns:

   1. Emoji emoji and formatting variability — if devs add extra spacing or change emoji, parsing breaks.
   2. No schema validation — if routing.md is hand-edited, malformed rows will silently produce incomplete modules.

   Recommendations:

   1. Implement a strict parser in \generate-repo-registry.mjs:

      • Skip blank lines and header separators (lines 1-3).
      • Extract cells with regex: \|\s*([^]+|\S+)\s*|\s*(\S+.?)\s|\s*(.?)\s|\
      • Validate each row: module path exists in \src/, primary/secondary are non-empty.
      • Fail loudly if parsing fails (don't silently omit modules).

   2. Add a test: Parse a fixture routing.md table and assert correct module count & structure.

   3. Add a comment to routing.md (as per AC):

      This table is machine-read by \scripts/generate-repo-registry.mjs. Changes to column order or emoji will break parsing. Do not edit the header separators; only add/update rows.

   ---

   4. ✅ registry-utils API: Complete

   Assessment: The proposed API surface is well-chosen. All four functions are necessary and sufficient for #733's use case.

   Proposed API:

   • \loadRegistry()\ — Load & parse JSON
   • 
     esolveFileToModule(filePath)\ — File → Module lookup
   • \getFileCriticality(filePath)\ — File → Criticality tier
   • \getModuleOwner(module)\ — Module → Owner
   • \getPackageForFile(filePath)\ — File → Package

   Additional utility (consider):

   • *\getSecondaryOwner(module)* — Explicitly return secondary owner. This is useful for PR impact analysis (notify primary first, secondary as reviewer).

   • *\getModulesByOwner(owner)* — Reverse lookup for feat: PR architectural impact analysis — blast radius, module boundaries, reviewer routing #733's risk scoring. Return all modules owned by a given agent, grouped by criticality.

   These additions won't break #670 or #733, but they'll make #733 more elegant.

   ---

   5. ✅ Fallback Handling: Default to "unknown"

   Assessment: This is correct. Proposal from issue doesn't specify, but here's the right approach:

   Recommendation:

   \\javascript
   function resolveFileToModule(filePath) {
   // Exact match on module paths (e.g., "src/adapter/foo.ts" → "src/adapter/")
   for (const [module, _] of Object.entries(registry.modules)) {
   if (filePath.startsWith(module)) {
   return module;
   }
   }
   // Fallback: return a special marker object
   return {
   module: "unknown",
   primary: null,
   package: null,
   criticality: "unknown"
   };
   }
   \\

   This ensures:

   • feat: PR architectural impact analysis — blast radius, module boundaries, reviewer routing #733 doesn't crash on unmatched files (CI always completes).
   • Impact scoring degrades gracefully (unmatched files get lowest priority).
   • Easy to spot in reports — developers see "unknown" and know to update routing.md.

   Alternative: Throw an error if strict validation is desired, but that feels too harsh for repo churn.

   ---

   6. ⚠️ Criticality Tiers: Recommend Hardcoded (for now)

   Assessment: Hardcoding is the right starting point. Configurability adds complexity that isn't yet justified.

   Recommended hardcoded tiers:

   \\javascript
   const CRITICALITY_TIERS = {
   CRITICAL: { level: 1, label: "critical", impact: 10 },
   HIGH: { level: 2, label: "high", impact: 5 },
   MEDIUM: { level: 3, label: "medium", impact: 2 },
   LOW: { level: 4, label: "low", impact: 1 },
   UNKNOWN: { level: 5, label: "unknown", impact: 0 }
   };
   \\

   Why hardcoded now:

   • No use case yet justifies configuration overhead.
   • fix: squad.agent.md silently disappears after upgrade when template source is missing #730 (agent file resilience) and feat: PR architectural impact analysis — blast radius, module boundaries, reviewer routing #733 (PR impact) are the first consumers; neither needs tuning.
   • Easy to extract into a config file later if a third consumer needs it.

   ✅ Keep hardcoded for now.

   ---

   7. ✅ Committed JSON: Right Approach

   Assessment: Committing the generated JSON is the correct decision.

   Why:

   1. Determinism: CI can verify registry freshness by diffing (proven pattern with template-sync.test.ts).
   2. No runtime overhead: feat: PR architectural impact analysis — blast radius, module boundaries, reviewer routing #733's analyze-impact.mjs loads a static JSON, not parsing routing.md in production.
   3. Git history: Diffs show exactly what changed between releases (e.g., "src/cli/ reassigned from EECOM to Network").
   4. PR feedback: Reviewers see the impact of routing.md changes in the diff — transparent.

   Concern (already addressed by design):

   The registry can drift if source files are edited without regenerating. But the CI test (
   egistry-sync.test.ts) catches this — same pattern as \ emplate-sync.test.ts.

   ✅ Committed JSON is correct.

   ---

   8. ✅ Forward Compatibility with #670

   Assessment: The schema gracefully supports #670's extensions.

   Current schema (issue #736):

   \\jsonc
   {
   "modules": { "src/adapter/": { "primary": "...", "secondary": "...", "package": "..." } },
   "criticalFiles": [{ "path": "...", "tier": "critical", "source": "..." }]
   }
   \\

   How #670 can extend it:

   \\jsonc
   {
   "modules": {
   "src/adapter/": {
   "primary": "...",
   "secondary": "...",
   "package": "...",
   // NEW: version lineage (non-breaking addition)
   "versions": [
   { "version": 1, "layout": "classic", "migrationPath": "auto", "readTargets": ["..."], "writeTargets": ["..."] }
   ]
   }
   }
   }
   \\

   This is forward-compatible:

   • Old code ignores the \�ersions\ key.
   • New code (PRD: Versioned file layout manifest - single source of truth for directory structure #670) checks for it and adapts.
   • No breaking changes.

   ✅ Schema is extensible.

   ---

   9. 📋 Minor Gaps to Close

   Missing from AC:

   1. Error handling in generator:

      • What if routing.md is malformed? (Should fail loudly + suggest fix.)
      • What if a module path doesn't exist? (Warn, but don't skip.)
      • What if templates.ts can't be parsed? (Throw explicit error.)

   2. TypeScript types: Consider adding a .d.ts\ file for
      egistry-utils.mjs\ so consuming code (e.g., feat: PR architectural impact analysis — blast radius, module boundaries, reviewer routing #733's analyze-impact.mjs) gets IDE hints.

   3. Performance note: Parsing routing.md on every build is O(modules) and negligible, but if it ever becomes O(n²), document that concern.

   ---

   10. 🎯 Recommendation: Proceed with Minor Revisions

   This issue is ready to code with these clarifications:

   1. ✅ Add \metadata.source_hash\ to schema (for determinism).
   2. ⚠️ Add strict Markdown parsing with detailed error messages.
   3. ⚠️ Consider \getSecondaryOwner()\ and \getModulesByOwner()\ in registry-utils.
   4. ✅ Hardcode criticality tiers (no config file).
   5. ✅ Add a note to routing.md warning developers not to change column separators.
   6. 📝 Add TypeScript types for registry-utils exports.

   Build order looks good:

   • feat: repo registry — machine-readable module/file/owner/criticality map #736 → feat: PR architectural impact analysis — blast radius, module boundaries, reviewer routing #733 (parallel) + PRD: Versioned file layout manifest - single source of truth for directory structure #670 (parallel)

   Estimated effort: Still 1 session. The additions above are straightforward.

   ---

   Sign-Off

   As Flight (🏗️ Architecture): This design is sound. It's a proper foundation for the distributed ownership tracking that Squad needs. I'm confident it will serve #733 and #670 well.

   Proceed with implementation. I'll review the generated code when it's ready.
3. diberry commented on Apr 2, 2026

   

   diberry

   on Apr 2, 2026

   ContributorAuthor

   More actions

   FIDO Test Strategy Review — Issue #736

   Hey Dina, I've reviewed the repo registry proposal. Here's my testing assessment:

   ✅ **1. Is \

   egistry-sync.test.ts\ (regenerate + diff) sufficient?**

   Yes, with conditions. The template-sync pattern is excellent and directly transfers:

   • ✅ Dynamic enumeration (all files from routing.md must exist in registry.json)
   • ✅ Script execution guard (generate-repo-registry.mjs must exit 0)
   • ✅ Byte-for-byte parity (regenerated JSON must match committed JSON)
   • ✅ CI gate (fails the PR if stale — prevents manual JSON edits)

   But watch for these edge cases:

   1. Partial regeneration failures — if routing.md has 20 modules but generate-repo-registry.mjs crashes on module Add Ralph — built-in work monitor squad member #15, the diff test won't catch it. Add a test that validates the schema structure (module counts, required fields).
   2. Missing source files — if routing.md moves or templates.ts is deleted, the generator should fail loudly with clear error messages. Test that.
   3. Parsing conflicts — if two different parsing approaches (regex on routing.md vs AST on templates.ts) disagree on the same module name, the registry will be corrupted silently. I'd add a conflict-detection test.

   ---

   🟡 **2. Should there be unit tests for \

   egistry-utils.mjs\ functions individually?**

   Yes, definitely. These are utilities that other scripts (#670, #733) will import. Unit tests protect downstream consumers.

   Per-function test strategy:

   • *\loadRegistry()* — Test that it parses valid JSON, fails with clear errors on malformed JSON, handles missing file gracefully
   • *
     esolveFileToModule()* — Complex enough to warrant edge case testing (see question 5)
   • *\getFileCriticality()* — Verify fallback logic: if file not in criticalFiles[], should it return null or a default tier? Document the contract.
   • *\getModuleOwner()* — Test that it returns both primary and secondary correctly, handles missing modules gracefully
   • *\getPackageForFile()* — Verify path matching logic (nested dirs vs roots)

   I'd create a separate \ est/registry-utils.test.ts\ with mocked registry fixtures. This keeps sync tests focused on freshness, utils tests focused on correctness.

   ---

   🔴 **3. What happens if \

   outing.md\ format changes? Should tests verify parsing?**

   Absolutely yes. This is a critical dependency. I'd add:

   1. Positive case — Parse a well-formed routing.md table, verify all 20 modules are extracted

   2. Negative cases:

      • Missing |Primary|Secondary|\ header
      • Malformed pipes (e.g., extra spaces that break alignment)
      • Duplicate module names
      • Missing module row
      • Extra columns added (should still parse the expected columns)

   3. Regression test — If routing.md format ever broke in the past, encode that pattern as a negative test.

   The generator should fail loudly if parsing is ambiguous. No silent data loss.

   ---

   🟢 4. Should there be snapshot tests for the generated JSON?

   Not necessary in addition to regenerate-diff, but consider inline validation:

   The regenerate-diff pattern already validates structure via comparison. However, I'd recommend adding schema validation tests:

   • Validate the JSON against a schema file (.squad/repo-registry.schema.json)
   • Verify every module has \primary, \secondary, \package\
   • Verify every critical file has \path, \ ier, \source\
   • Verify enum constraints (\ ier\ must be one of: critical, high, medium, low)

   This catches structural issues that byte-for-byte comparison doesn't. Use \json-schema-validator\ or similar.

   ---

   ⚠️ **5. How to test \

   esolveFileToModule()\ — what edge cases matter?**

   High-value test cases:

   1. Root files — What does
      esolveFileToModule('package.json')\ return? Should map to the root package or fail? Decide and test both behaviors.
   2. Nested dirs — \src/adapter/client.ts\ should resolve to \src/adapter/, not \src/. Test that the longest matching prefix wins.
   3. Non-existent paths — \src/nonexistent/foo.ts\ should return null or throw? Test and document the contract.
   4. Symlinks — If registry paths use symlinks, does resolution follow them? Test on Windows too (symlinks behave differently).
   5. Case sensitivity — On macOS/Windows, does \SRC/adapter/\ match \src/adapter/? Test and explicitly document the contract.
   6. Overlapping paths — If registry has both \src/cli/\ and \src/cli/commands/, which wins for \src/cli/commands/foo.ts? Longest match should win; test it.

   Add these as a parametrized test suite in
   egistry-utils.test.ts.

   ---

   ✅ 6. Is the template-sync pattern the right model, or are there better approaches?

   The template-sync pattern is solid here. It directly maps:

   • sync-templates.mjs → generate-repo-registry.mjs (both extract from sources, produce files)
   • template-sync.test.ts → registry-sync.test.ts (both regenerate and diff)
   • Canonical sources (routing.md, templates.ts) → Committed artifact (repo-registry.json)

   One caveat: Template sync has the luxury of byte-for-byte comparison because template files are mostly static. Registry JSON, however, includes a generated timestamp. Decide now:

   • Option A: Strip the timestamp before diffing (my recommendation — it's not semantic)
   • Option B: Include timestamp and expect regeneration on every CI run (wastes diffs, adds noise)

   If you go with Option A, add a helper that normalizes timestamps before comparison:
   \\ s
   function normalizeRegistry(json: string): string {
   const obj = JSON.parse(json);
   obj.generated = 'TIMESTAMP_NORMALIZED_FOR_TESTING';
   return JSON.stringify(obj, null, 2);
   }
   \\

   ---

   📋 Test Summary — My Recommendation

   1. ✅ registry-sync.test.ts — Regenerate + diff (like template-sync)
   2. ✅ registry-utils.test.ts — Unit tests for each exported function (new file)
   3. ✅ routing.md parsing tests — Negative cases, format resilience (in registry-utils or sync test)
   4. ✅ Schema validation — Inline checks in sync test (or separate schema.test.ts)
   5. ✅ resolveFileToModule() edge cases — Parametrized test in registry-utils.test.ts
   6. ✅ Timestamp handling — Normalize before diff to avoid CI flakiness

   Effort: The sync test is ~1-2h (copy template-sync pattern). Utils tests + edge cases + schema validation: ~3h. Total: ~4h of test work, well worth it for a shared data layer that #670 and #733 both depend on.

   ---

   Ready to start implementation. Flag me if you want me to spike the test structure first or just build it in parallel with the generator script. 🧪
4. diberry commented on Apr 2, 2026

   

   diberry

   on Apr 2, 2026

   ContributorAuthor

   More actions

   🔍 CI/Freshness Approach Review — Issue #736 (Repo Registry)

   Summary

   The issue proposes a generated repo registry JSON that stays current via a CI test (test/registry-sync.test.ts) following the pattern of template-sync.test.ts. Below is a detailed review of your CI/freshness strategy against the six key concerns.

   ---

   1. Vitest Test vs. CI Workflow Step ✅ RECOMMEND: Vitest Test

   Your approach: CI test that regenerates and diffs
   Assessment: CORRECT. This is the right pattern for this repo.

   Why:

   • Matches the proven template-sync.test.ts pattern (dynamic sync guard using vitest + execSync)
   • Fast feedback loop — developers run npm test locally before push
   • Semantic: The registry is data integrity, not a workflow concern
   • Low overhead — no separate job spinning up

   What NOT to do:

   • Don't add a separate GitHub Actions step (slow, harder to debug locally)
   • Don't make it a prebuild hook (would block builds unnecessarily)

   ---

   2. Where in CI Pipeline? ✅ ALONGSIDE TESTS (No Separate Job)

   Current pattern in squad-ci.yml:

   test job:
     - Checkout & setup
     - Fix stale lockfile
     - npm install
     - Source tree canary check
     - Large deletion guard
     - npm run build
     - npm test  ← HERE: vitest runs, including registry-sync.test.ts
   

   Recommendation: Place test/registry-sync.test.ts as a standard vitest suite.

   Why no separate job:

   • Minimizes CI overhead (already spinning up one test environment)
   • Easier to debug — developers see all test failures together
   • Consistent with template-sync.test.ts (also runs in npm test)

   CI Benefits:

   • ✅ Runs on every PR (squad-ci.yml triggers on pull_request + push to dev/insider)
   • ✅ Fails PR if registry is stale
   • ✅ Same timeout/retry logic as other tests

   ---

   3. Should npm run registry Be in prebuild? ❌ RECOMMEND: On-Demand Only

   Current prebuild (package.json:11):

   "prebuild": "node scripts/bump-build.mjs && node scripts/sync-skill-templates.mjs && node scripts/sync-templates.mjs"

   Recommendation: Do NOT add registry to prebuild. Keep it on-demand.

   Why:

   • Developers own the workflow: edit routing.md → run npm run registry → commit → push
   • Prebuild is for automatic sync: templates must sync before every build (they're embedded/copied)
   • Registry is committed JSON: not derived during build, so no tight coupling needed
   • Failure isolation: if registry generation fails, it doesn't break your build — you can still develop
   • CI catches drift: the test will fail, blocking the PR

   When they WOULD run it:

   # After editing routing.md:
   npm run registry
   
   # Or explicitly:
   node scripts/generate-repo-registry.mjs

   ---

   4. CI Detects Stale Registry? ✅ YES — Test Will Catch It

   Scenario: Developer edits routing.md, forgets to run npm run registry, pushes PR.

   What happens:

   1. CI: npm test → test/registry-sync.test.ts runs
   2. Test regenerates registry from source files (routing.md + templates.ts + package.json)
   3. Test diffs against committed .squad/repo-registry.json
   4. DIFF FOUND → test fails → PR blocks

   Exact pattern (from template-sync.test.ts lines 150–159):

   describe('registry-sync generation', () => {
     it('exits with code 0 (no stale registry)', () => {
       const output = execSync('node scripts/generate-repo-registry.mjs', {
         cwd: ROOT,
         encoding: 'utf-8',
         timeout: 30_000,
       });
       // Then diff against .squad/repo-registry.json
       expect(regeneratedRegistry).toEqual(committedRegistry);
     });
   });

   ✅ This WILL catch the forgotten regeneration.

   ---

   5. Should Generator Auto-Commit or Just Fail? ❌ RECOMMEND: Fail (No Auto-Commit)

   Our pattern: Fail on stale data, require developer action.

   Why NO auto-commit:

   • Developer intent: They must choose when registry reflects their change
   • Auditability: Every registry update is intentional, tracked in commit history
   • Prevents cascading updates: If CI auto-commits, you'd have hidden side effects on PRs
   • Matches template pattern: sync-templates.mjs doesn't auto-commit either; developers run it + commit

   Developer workflow:

   # 1. Edit routing.md
   vim .squad/routing.md
   
   # 2. Regenerate
   npm run registry
   
   # 3. Commit (now includes both routing.md + repo-registry.json)
   git add .squad/routing.md .squad/repo-registry.json
   git commit -m "feat: add module X to routing"

   If they forget step 2:

   • PR CI fails: test/registry-sync.test.ts → "registry is stale"
   • PR message prompts: npm run registry && git add .squad/repo-registry.json && git push

   ---

   6. .mjs Extension Consistency? ⚠️ MIXED — Repo Uses Both

   Current practice in scripts/:

   • ✅ .mjs files: sync-templates.mjs, generate-api-docs.mjs, check-exports-map.mjs, bump-build.mjs
   • ✅ Package.json scripts all call .mjs files with node scripts/*.mjs
   • ✅ CI runs them directly: node scripts/sync-templates.mjs

   Recommendation for your generator: Use .mjs (keep consistency).

   {
     "scripts": {
       "registry": "node scripts/generate-repo-registry.mjs"
     }
   }

   Why:

   • ES modules (top-level import syntax) are the repo standard
   • Shebang works: #!/usr/bin/env node
   • No compatibility issues with Node 22.5+
   • ✅ Matches all existing scripts

   ---

   📋 Acceptance Criteria Checklist

   From issue #736, verify these before merging:

   • scripts/generate-repo-registry.mjs parses routing.md + templates.ts + package.json → valid JSON (6 keys: generated, generator, modules, criticalFiles, packages, templateFiles)
   • .squad/repo-registry.json committed with all 20 modules, critical files, packages, template references
   • scripts/registry-utils.mjs exports 5 functions: loadRegistry(), resolveFileToModule(), getFileCriticality(), getModuleOwner(), getPackageForFile()
   • test/registry-sync.test.ts follows template-sync pattern: regenerates + diffs, fails if stale ✓
   • package.json has "registry": "node scripts/generate-repo-registry.mjs" script
   • package.json scripts do NOT add registry to prebuild
   • .squad/routing.md updated with comment: "Machine-readable alternative: see .squad/repo-registry.json"
   • No product code (SDK/CLI) changes, only repo tooling

   ---

   🔧 Implementation Notes

   File structure (when complete):

   scripts/
     ├─ generate-repo-registry.mjs       (new — generator)
     └─ registry-utils.mjs               (new — utilities)
   
   test/
     └─ registry-sync.test.ts            (new — CI guard)
   
   .squad/
     └─ repo-registry.json               (new — generated output, committed)
   

   Test will import both:

   // test/registry-sync.test.ts
   import { loadRegistry } from '../scripts/registry-utils.mjs';
   import { execSync } from 'node:child_process';

   ---

   ✅ Summary

   Question	Recommendation	Confidence
   Vitest test or CI step?	Vitest test (matches template-sync pattern)	🟢 High
   Where in pipeline?	In npm test job (no separate job needed)	🟢 High
   npm run registry in prebuild?	No, on-demand only (developers own workflow)	🟢 High
   CI detects stale registry?	Yes — test diffs against committed JSON	🟢 High
   Auto-commit or fail?	Fail & require developer action (intentional, auditable)	🟢 High
   .mjs consistency?	Yes, use .mjs (matches repo standard)	🟢 High

   Status: Approach is solid. Ready to implement. 🚀
5. diberry

   added 3 commits that reference this issue on Apr 2, 2026

   feat(registry): add repo registry — machine-readable module/file/owne…

   ...

   1f56c2d

   feat(registry): add repo registry — machine-readable module/file/owne…

   ...

   bc87f79

   feat(registry): add repo registry — machine-readable module/file/owne…

   ...

   5658765
6. diberry commented on Apr 6, 2026

   

   diberry

   on Apr 6, 2026

   ContributorAuthor

   More actions

   ✈️ Flight PRD Assessment

   Verdict: PRD is complete and ready for implementation.

   The issue body is a full PRD with schema, deliverables table, and implementation guide. This is the data foundation that #748 and #670 build on.

   Strengths:

   • Registry JSON schema is fully specified with modules (20 entries), critical files, and package workspace map
   • Generator reads from three authoritative sources (routing.md, templates.ts, package.json)
   • CI sync test (registry-sync.test.ts) prevents drift — follows the proven template-sync.test.ts pattern
   • Content hash metadata enables deterministic rebuild detection

   Assessment:

   • Deliverables are concrete: 5 files, each with clear purpose
   • Blocks feat: registry query layer — shared foundation for layout manifest (#670) and impact analysis (#733) #748 (query layer) and PRD: Versioned file layout manifest - single source of truth for directory structure #670 (layout manifest)
   • No missing sections — schema, API, tests, and CI are all specified

   Dependency chain (reconfirmed):

   1. feat: repo registry — machine-readable module/file/owner/criticality map #736 (this) → ships first, provides data
   2. feat: registry query layer — shared foundation for layout manifest (#670) and impact analysis (#733) #748 → query layer on top of registry
   3. PRD: Versioned file layout manifest - single source of truth for directory structure #670 → layout manifest consuming query layer

   Recommendation: Highest-priority in the registry chain. Ship this to unblock #748 and #670.
7. diberry commented on Apr 8, 2026

   

   diberry

   on Apr 8, 2026

   ContributorAuthor

   More actions

   Closing: implementation PR #737 was closed without merging. Foundation needs re-evaluation if/when prioritized. Dependency chain (#748, #670) also being closed.
8. diberry

   closed this as completedon Apr 8, 2026