Requirement IDs with no implementation (GitLab)

The problem this solves

Requirement IDs get sprinkled through docstrings and test names, then the model moves on and the references stay, pointing at nothing. The reverse query is easy to run and useless, because most unreferenced requirements are simply not built yet.

How it works

Code claiming requirements that no longer exist, filed as GitLab issues for the orphans only. The same reconciliation as the GitHub version, with issue creation on GitLab. Orphans are reported in full; unreferenced requirements are grouped by status and never filed one by one.

You are reconciling requirement IDs referenced in a codebase against
the software requirements in the Dalus model [model name]. The
valuable finding is code claiming a requirement that no longer
exists. The second finding, requirements with no code reference, is
reported but treated with restraint.

CONFIRM FIRST, in one message: which Dalus model, which repository,
which branch, and how requirement IDs are written in the code
(docstrings, test names, comments, annotations, commit trailers).
Also ask which paths to include or exclude, since vendored and
generated code will produce noise. Ask anything else in the same
message. Then begin.

ESTABLISH THE ID CONVENTION before scanning. Infer the ID pattern
from a sample of the code and from the model's ID format, show the
user the pattern you will match and five real examples you found, and
have them confirm it. A wrong pattern produces a wrong report in both
directions.

SCAN THE REPOSITORY for every requirement ID reference: docstrings,
test names, comments, annotations, configuration, documentation in
the repo. Record for each: the ID, the file, the line, and whether it
appears in production code, in a test, or in documentation. A
requirement referenced only in a test is a different fact from one
referenced in implementation, and the report keeps them apart.

READ THE MODEL: all requirements with IDs, statements, status,
allocation, and which are allocated to software. Also read
requirements not allocated to software, since code may reference them
and that is itself worth knowing.

LIST 1, THE ORPHANS, reported first and in full. Requirement IDs
referenced in code that do not exist in the model. For each, work out
which case it is and say so:
- The requirement was renamed or renumbered: name the likely current
  requirement and the evidence for the match (statement similarity,
  same allocation), clearly marked as a suggestion.
- The requirement was deleted: state that no plausible successor
  exists.
- The ID never existed: a typo or a convention the model never used.
- The ID belongs to another model or an external specification.
Sort orphans by how many code locations reference them, since a stale
ID referenced in thirty places is a bigger cleanup than one in a
single comment.

LIST 2, THE UNREFERENCED REQUIREMENTS, reported second and with
restraint. Requirements allocated to software with no reference
anywhere in the code. Report this as a count with a grouped
breakdown by status, not as a flat list of everything unstarted.
Separate:
- Requirements whose model status says complete or verified but that
  have no code reference. These are the interesting ones and are
  worth attention.
- Requirements still open or in progress. These are normal and are
  reported as a count only, expandable on request.
Never file an issue per unimplemented requirement.

ALSO REPORT, briefly: requirements referenced only in tests and never
in implementation, and requirements referenced in code but not
allocated to software in the model, which usually means the
allocation is wrong.

RECONCILE: total distinct IDs found in code equals matched plus
orphans. Total software requirements equals referenced plus
unreferenced. Show both.

GITLAB ISSUES, gated. Propose one issue per orphan, never per
unreferenced requirement, unless the user explicitly asks otherwise.
Each proposed issue: title naming the stale ID, body listing every
file and line referencing it, the suggested successor requirement if
one exists with the evidence for that suggestion, and a note that the
correct fix may be updating the code reference or restoring the
requirement. Group orphans that share a likely successor into one
issue. Show the full set of drafts and wait for approval before
creating anything. Never set assignees or milestones.

AFTER CREATING: report issue numbers, what was skipped, and anything
that failed. Then offer (do not execute) a follow-up run scoped to
the requirements with complete status and no implementation, since
that list is the one worth a real conversation.

THIS WORKFLOW IS READ-ONLY on the model and the code. It writes only
GitLab issues, and only after approval.

Replace the [bracketed] placeholders with your model and project names.

What you get

Common questions