DLLPickle Gap Register

This directory tracks open maintenance traps, automation gaps, and unresolved architecture follow-ups that should remain visible to maintainers and agentic workstreams.

Use this register for durable repo-local gap state. Use docs/superpowers/specs/ and docs/superpowers/plans/ for larger point-in-time designs and task-by-task implementation plans.

Rules for maintainers and agents

1. Treat each GAP-*.md file as the source of truth for that gap’s current status.
2. Do not mark a gap resolved unless all acceptance criteria in the gap file are checked or explicitly superseded.
3. When resolving a gap, update:
4. the gap file,
5. this index,
6. related tests,
7. related source, policy, or workflow files,
8. related documentation,
9. docs/Architecture.md when architecture, invariants, validation gates, source-of-truth mappings, or known gaps changed.
10. If a gap becomes obsolete because of a different design, mark it superseded, explain why, and link the superseding PR, issue, or document.
11. If a gap cannot be completed safely, mark it blocked, explain the blocker, and leave the remaining acceptance criteria unchecked.
12. Keep this index synchronized with each gap file’s frontmatter.

Status values

Status	Meaning
open	Known gap with no active implementation PR.
in-progress	Implementation is underway in a linked PR or branch.
blocked	Work cannot proceed without an external decision, credential, environment, or dependency.
resolved	Acceptance criteria are complete and the resolving PR is linked.
superseded	A later design or decision made the gap obsolete.
wont-fix	The gap is accepted intentionally, with rationale documented.

Gap index

ID	Status	Area	Title	File
GAP-001	resolved	dependency-policy	Add dependency policy realization guard	GAP-001
GAP-002	resolved	dependency-policy	Track Az.Resources as a monitored collision source	GAP-002
GAP-003	open	runtime-probes	Add representative EXO and Teams probe commands	GAP-003
GAP-004	open	host-context	Model VS Code and PowerShellEditorServices host behavior	GAP-004
GAP-005	resolved	known-conflicts	Strengthen OData conflict expectation management	GAP-005
GAP-006	resolved	release-process	Document manual release dispatch process trap	GAP-006
GAP-007	open	branch-protection	Audit required status-check ruleset configuration	GAP-007
GAP-008	open	module-manifest	Guard manifest export drift	GAP-008
GAP-009	open	build-output	Make merged root-module script order deterministic	GAP-009
GAP-010	resolved	review-process	Define unresolved review-thread maintenance workflow	GAP-010
GAP-011	resolved	documentation	Guard docs and implementation drift for gap closures	GAP-011

Agent workflow

1. Start with the requested GAP-*.md file.
2. Read every file listed in related_docs.
3. Search the repository for the gap ID before editing.
4. Make the smallest safe implementation that satisfies the acceptance criteria.
5. Add or update tests before marking a gap resolved when an automated guard is practical.
6. Update related documentation before finalizing the PR.
7. Update this index and the gap file frontmatter in the same PR that resolves, blocks, supersedes, or intentionally accepts the gap.

Automated guard

tests/Unit/GapRegister.Tests.ps1 structurally validates this register on every unit-test run. It fails the build when:

• a GAP-*.md file declares a status outside the allowed values above,
• a GAP-*.md file is missing from the gap index table,
• a gap file’s frontmatter status does not match its index row, or
• a gap index row File-column link basename does not match its actual GAP-*.md filename, or
• a resolved gap is missing resolution_pr or resolved_on.

The guard is deterministic and local-only; it does not call the GitHub API. Whether the related_docs of a resolved gap were actually updated remains a review-only check, because that cannot be verified structurally without false positives.