Goal
Turn a verified inventory of small repository maintenance frictions into a set of domain-clustered, independently reviewable subissues, so each friction is fixed in its own small pull request and under the EPIC that already owns its domain. This EPIC is planning-only: it changes no code, configuration, or documentation outside its own specification and the subissue specifications it produces.
Why
Routine work keeps running into the same small defects: a developer-tool test suite red on develop since it was moved, three such suites that no orchestrator runs, sixteen specifications for closed issues still in the open backlog, a workflow trigger that starts a job on branches it immediately refuses, and documentation pointing at binaries that have since moved into a package. None was large enough to justify its own issue when it was found and none blocks a feature, so each has survived several release cycles. Individually they are noise; collectively they are a standing tax on every contributor and agent who reads a stale path, re-diagnoses a red test, or scrolls past a run that was never going to succeed.
Fixing them in one pull request was the first proposal and was rejected: a single change touching workflows, shell fixtures, Rust source, documentation, and sixteen directory moves is hard to review and hard to revert item by item, and it hides the items that belong to an EPIC that already owns their surface.
Scope
- Keep the verified inventory as the durable record behind every subissue, with each item's evidence held in the subissue specification that owns it.
- Assign every inventory item to the EPIC whose own stated scope covers it, and record the argument for that assignment.
- Produce one draft subissue specification per item or group of items sharing a domain, each sized for one focused pull request.
- Create the GitHub subissues from the approved drafts, attach them to their parent EPIC, and move each specification into
docs/issues/open/.
- Track completion until every inventory item is delivered or explicitly closed as won't-fix.
Out of scope: fixing any friction in this EPIC's own pull request; re-verifying the inventory; archival automation, which is #1774; external-link triage, which is #2185; the Docker E2E repair, which is #2179; folder-style spec migration, which is #2159; and the long-term check-harness architecture, which is EPIC #2003.
Subissues planned
Owned by this EPIC:
- Narrow the container workflow release-branch trigger
- Correct stale documentation references left by completed moves and decisions
- Archive the issue specifications of closed issues
- Remove the unquotable character-type generic from the workspace-coupling tool
- Widen the allowed-actions allowlist entry that pins an exact patch version
- Resolve the two dependency update pull requests stalled since August
Handed to EPIC #2003, under its stated exception for low-risk, additive, independently verifiable work:
- Repair the project dictionary formatter test suite
- Run the developer-tool test suites in CI
Standalone, with no parent, because it is a behavioural change to a user-facing error path and the configuration overhaul EPIC that would have owned it is closed:
- Report an unsupported configuration schema version instead of an unknown-field error
Spec
docs/issues/open/2190-maintenance-frictions-cleanup/EPIC.md, under review in #2193.
Goal
Turn a verified inventory of small repository maintenance frictions into a set of domain-clustered, independently reviewable subissues, so each friction is fixed in its own small pull request and under the EPIC that already owns its domain. This EPIC is planning-only: it changes no code, configuration, or documentation outside its own specification and the subissue specifications it produces.
Why
Routine work keeps running into the same small defects: a developer-tool test suite red on
developsince it was moved, three such suites that no orchestrator runs, sixteen specifications for closed issues still in the open backlog, a workflow trigger that starts a job on branches it immediately refuses, and documentation pointing at binaries that have since moved into a package. None was large enough to justify its own issue when it was found and none blocks a feature, so each has survived several release cycles. Individually they are noise; collectively they are a standing tax on every contributor and agent who reads a stale path, re-diagnoses a red test, or scrolls past a run that was never going to succeed.Fixing them in one pull request was the first proposal and was rejected: a single change touching workflows, shell fixtures, Rust source, documentation, and sixteen directory moves is hard to review and hard to revert item by item, and it hides the items that belong to an EPIC that already owns their surface.
Scope
docs/issues/open/.Out of scope: fixing any friction in this EPIC's own pull request; re-verifying the inventory; archival automation, which is #1774; external-link triage, which is #2185; the Docker E2E repair, which is #2179; folder-style spec migration, which is #2159; and the long-term check-harness architecture, which is EPIC #2003.
Subissues planned
Owned by this EPIC:
Handed to EPIC #2003, under its stated exception for low-risk, additive, independently verifiable work:
Standalone, with no parent, because it is a behavioural change to a user-facing error path and the configuration overhaul EPIC that would have owned it is closed:
Spec
docs/issues/open/2190-maintenance-frictions-cleanup/EPIC.md, under review in #2193.