Context
The "content-lane" registry-review subsystem (src/review/content-lane/** + src/review/content-lane-wire.ts) is the deterministic, AI-free adjudicator for registry-style submission PRs (append an entry to a JSON array in a tracked file, e.g. <slug>.json::surfaces[]). It's parameterized by a RegistryLaneSpec interface (src/review/content-lane/registry-logic.ts) so it isn't supposed to be hard-coded to any one repo — but naming and export choices made when it was first built (for our own dogfood repo, metagraphed) leak repo-specific identifiers into what's meant to be shared, generic surface.
This is the first of a small chain of issues (see #2 and #3, tracked under the parent roadmap) that make the content-lane engine actually reusable by any self-hosted maintainer's own registry repo, per the "Modular & config-driven — never hard-coded for one repo" guiding principle of the parent epic.
Requirements
src/review/content-lane-wire.ts exports the host-adapter entrypoint under a name that hard-codes one repo's identity. Rename it to a generic name that accurately describes what it does regardless of which registry is configured.src/review/content-lane/index.ts's public barrel re-exports a submodule that is entirely specific to one registry's domain (chain-identity verification helpers) alongside genuinely generic, spec-driven primitives (scope classification, duplicate detection, etc.). Stop re-exporting the domain-specific submodule from the generic barrel — keep it reachable via a direct import from its own file, since it's still legitimate code (just not generic API).- The barrel's own header doc comment lists that submodule as a "ported" generic primitive — correct the comment to describe it accurately as one registry's own domain plumbing, not shared infrastructure.
- No behavior change. This is a rename + export-surface cleanup only.
Deliverables
Expected outcome
Nothing outside src/review/content-lane* still implies (via a symbol's name or its export location) that the content-lane engine only works for one repo. A maintainer reading the public API surface can tell, from naming alone, what's generic engine vs. one registry's own domain code.
Context
The "content-lane" registry-review subsystem (
src/review/content-lane/**+src/review/content-lane-wire.ts) is the deterministic, AI-free adjudicator for registry-style submission PRs (append an entry to a JSON array in a tracked file, e.g.<slug>.json::surfaces[]). It's parameterized by aRegistryLaneSpecinterface (src/review/content-lane/registry-logic.ts) so it isn't supposed to be hard-coded to any one repo — but naming and export choices made when it was first built (for our own dogfood repo, metagraphed) leak repo-specific identifiers into what's meant to be shared, generic surface.This is the first of a small chain of issues (see #2 and #3, tracked under the parent roadmap) that make the content-lane engine actually reusable by any self-hosted maintainer's own registry repo, per the "Modular & config-driven — never hard-coded for one repo" guiding principle of the parent epic.
Requirements
src/review/content-lane-wire.tsexports the host-adapter entrypoint under a name that hard-codes one repo's identity. Rename it to a generic name that accurately describes what it does regardless of which registry is configured.src/review/content-lane/index.ts's public barrel re-exports a submodule that is entirely specific to one registry's domain (chain-identity verification helpers) alongside genuinely generic, spec-driven primitives (scope classification, duplicate detection, etc.). Stop re-exporting the domain-specific submodule from the generic barrel — keep it reachable via a direct import from its own file, since it's still legitimate code (just not generic API).Deliverables
npm run test:cigreen, coverage unaffected (no new logic, only renames/export changes).Expected outcome
Nothing outside
src/review/content-lane*still implies (via a symbol's name or its export location) that the content-lane engine only works for one repo. A maintainer reading the public API surface can tell, from naming alone, what's generic engine vs. one registry's own domain code.