T-BH1K-task-approach-verifies-downstream-constraint
State: open/ready · Impact: medium · Complexity: small
AUTO-DEFINED: this spec was best-effort machine-authored by /sdlc:task-auto-define on 2026-09-27 while driving this freshly-spawned follow-up task toward open/ready. Review the Goal, Approach, Today, Areas, and Acceptance criteria carefully before trusting it.
T-N63X’s post-mortem found the task’s own Approach guessed a 280-360px preview-width threshold from the file list’s floor alone, missing that the real binding constraint (~520px) lived one component away, in PolishLintPreviewPane.vue’s own header. A quick empirical check of the downstream component’s own minimum width, not just the nearest visible constraint, would have saved a design detour. Add guidance (a task-authoring convention or principle) that a task proposing a numeric threshold/range should verify the actual downstream constraint before finalizing it.
solutions/ontological/lib/model/entities/task/implementation-ready.md is
the shared contract every task-authoring skill (task-define,
task-auto-define, task-ensure-ready) checks a task’s body against. Its
## Body sections → “Optional in presence, typed when present” list
describes the Approach (or Plan) section as “concrete steps a
competent engineer could execute without further design. Not ‘investigate
X’ — that’s a research task, not an implementation plan.” That’s the whole
entry. It says nothing about where a proposed number in that section is
supposed to come from.
A task’s Approach can name a pixel width, a timeout, or a batch-size range
that reads as concrete — satisfying the existing “not investigate X” bar —
while still being wrong, because it was inferred from the nearest visible
constraint rather than checked against the component the number actually
targets. T-N63X-polish-lint-preview-narrow-collapse’s post-mortem
found exactly this: its Approach guessed a 280-360px preview-width
threshold from the file list’s own min-w-[280px] floor, but the real
binding constraint (~520px) lived one component away, in
PolishLintPreviewPane.vue’s own header. Nothing in the contract or the
skills that check against it prompts an author to verify that.
Proposed
Section titled “Proposed”Add one instruction to the same Approach entry in
implementation-ready.md: when the Approach proposes a numeric threshold
or range, it should record that the actual constraint was checked on the
specific downstream/dependent component the number targets — not inferred
from the nearest visible constraint. This is a documentation-only change:
a sentence added to an existing prose bullet, evaluated the same way the
neighboring “not investigate X” sentence already is (by a human or by
/sdlc:task-define / /sdlc:task-ensure-ready reading the Approach
section), not a new mechanical scanner rule or a new entry in the
## Disqualifiers list.
Approach
Section titled “Approach”- Open
solutions/ontological/lib/model/entities/task/implementation-ready.md. - In
## Body sections→### Optional in presence, typed when present, find the Approach (or Plan) bullet. - After its existing “Not ‘investigate X’ — that’s a research task, not an implementation plan.” sentence, add a sentence stating: when the Approach proposes a numeric threshold or range (a pixel width, a timeout, a batch size, and the like), it should record that the actual constraint was checked on the specific downstream/dependent component the number targets — not inferred from the nearest visible constraint one component away.
- Keep the added sentence generic: no citation of a specific past task,
PR, or incident.
implementation-ready.mdis durable contract prose, not a post-mortem log. - Touch no other file.
implementation-ready.mdis the single canonical source for this contract — it is not one of theSKILL.mdfiles agent-pants mirrors into.claude-plugin/,.cursor-plugin/,.agents/, andplugin/plugins/sdlc/, so there is no generated copy to keep in sync. - No frontmatter, schema, CLI, or scanner code changes. The edited file is
prose reference documentation, not an entity instance under
docs/planning/<plural>/, sosdlc entities validatedoes not apply to it.
| Area | Note |
|---|---|
solutions/ontological/lib/model/entities/task/implementation-ready.md | Where the new guidance sentence is added, in the Approach/Plan bullet under “Optional in presence, typed when present” |
Acceptance criteria
Section titled “Acceptance criteria”- AC-1:
solutions/ontological/lib/model/entities/task/implementation-ready.md’s Approach (or Plan) bullet contains added text instructing that a proposed numeric threshold or range be checked against the actual downstream/dependent component’s own constraint before finalizing the number, rather than inferred from the nearest visible constraint. - AC-2: The added text names no specific past task, PR, or incident — it stays generic, consistent with this doc’s role as durable contract prose.
- AC-3: The change touches only
implementation-ready.md— no CLI code, schema, or scanner logic changes, since this is authoring guidance, not a new mechanical disqualifier.
Out of scope
Section titled “Out of scope”- Building an automated/mechanical check that verifies a numeric threshold against a downstream component’s constraint. This task adds authoring guidance only.
- Retrofitting or auditing existing tasks whose Approach sections may already carry a guessed threshold.
- Adding a new entry to the
## Disqualifierslist inimplementation-ready.md(a hard, LLM-judged gate). This task extends the existing Approach bullet’s descriptive guidance, not a new disqualifier category.
Dependencies
Section titled “Dependencies”- none
Discovery context
Section titled “Discovery context”Spawned by /sdlc:spawn-task-pr on 2026-09-27 UTC from
T-N63X-polish-lint-preview-narrow-collapse in
git@github.com:sksizer/dev.git.