T-P02V-extract-task-file-resolution-into-a-deterministic-sdlc-op
Status: closed/done · Impact: medium · Complexity: medium
<Why this task exists. The problem it solves, the work it unblocks, or the risk it mitigates. Two or three sentences — the elevator pitch.>
<Current state of the relevant area as a typed table. One row per touched location; the Location column uses the five-form grammar documented in the template’s header comment. The Role-today column is a one-line note on what that location does today (or what’s wrong/missing there).
Pure-narrative Todays (no path-bearing rows) may also be expressed as prose — but tables are the preferred shape because the verifier resolves each row against the live codebase, so the description doesn’t go stale as code drifts.>
| Location | Role today |
|---|---|
path/to/file.ext | |
path/to/dir/ | <what’s in this directory today> |
Proposed
Section titled “Proposed”<Target state after this task ships. Concrete enough that an implementer can tell when they’re done. Not the steps — the destination.>
Approach
Section titled “Approach”<Numbered, ordered steps to get from Today to Proposed. Each step should be small enough to commit on its own if useful. Call out any decisions still open inside the step.>
Files to touch
Section titled “Files to touch”<Typed table of every location you expect to touch. Location uses the
same five-form grammar as ## Today (see header comment). Kind is one
of new, modify, or delete. Change is a one-line note on what
happens there.
The verifier resolves each row by Kind: new rows require no existing
file; modify and delete rows must resolve in the codebase (file /
symbol / dir must exist; glob must expand to ≥1 match). Symbols on
glob rows are rejected.>
| Location | Kind | Change |
|---|---|---|
path/to/file.ext | modify | |
path/to/new-file.ext | new |
Acceptance criteria
Section titled “Acceptance criteria”<Each AC must be observable from outside the change — a test that passes, a user-visible behavior, a removed wart. Avoid “the code is cleaner” style ACs; pick something verifiable.>
- AC-1:
- AC-2:
- AC-3:
Out of scope
Section titled “Out of scope”<Things adjacent to this task that are deliberately NOT being addressed here. Useful for keeping PR review focused and for future tasks to point back to. Always required: if scope is obvious and nothing is excluded, leave a single ”- none” bullet so the explicit signal is “scope considered, nothing to exclude.”>
- none
Dependencies
Section titled “Dependencies”<Other tasks, branches, infra changes, or external decisions this task
waits on. For hard “B cannot start until A closes” dependencies on
other tasks or epics, also record them in the frontmatter
depends_on: array (strict wikilink shape, e.g. [T-0010](/planning/tasks/T-0010/)) — the
audit walks that graph for cycle detection. This prose section is the
human-readable narrative; depends_on: is the machine-readable
canonical list. Leave a single ”- none” bullet if there are none.>
- <dependency or “none”>
Discovery context
Section titled “Discovery context”<Optional. How this task got onto the list: linked incident, design doc, upstream conversation, prior PR review comment. Helps future-you remember why this was worth doing. Delete this section if there’s nothing to add.>