artifact-conventions

name	artifact-conventions
description	Defines preservation, format, and section rules for SDD specification artifacts (spec.md, plan.md, tasks.md, checklists). Use when editing feature-artifact files under specs/<feature-folder>/ to prevent accidental corruption of cross-referenced IDs, priorities, and gating state.

Artifact Convention Rules

These rules apply whenever an agent reads or modifies files inside a Feature Workspace at specs/<feature-folder>/. They protect the integrity of cross-referenced identifiers, gating state, and structural conventions that downstream phases depend on. They do not apply to Project Context Specs such as specs/prd.md or specs/sad.md.

Preservation Rules

These are non-negotiable guardrails — violating them breaks cross-artifact traceability and phase gating.

Rule	Rationale
Do NOT reorder product user story priorities or non-product objective priorities (P1, P2, P3) without explicit user approval	Priority order drives task phasing and MVP scope — reordering silently changes what ships first
Do NOT change task IDs (T001, T002…)	Task IDs are cross-referenced in coverage maps, dependency graphs, and issue trackers
Do NOT change checklist IDs (CHK001, CHK002…)	Checklist IDs are referenced externally by quality-assurance checks and test evaluators
Preserve checkbox state (- [ ] vs - [X])	Checkbox state is a gating signal — flipping it can unblock or block downstream phases
Do NOT change requirement IDs (FR-001, TR-001, OR-001, RR-001)	Requirement IDs are mapped to tasks, coverage reports, and compliance checks
Do NOT change success criteria IDs (SC-001, SC-002…)	Success criteria IDs are referenced in phase reviews and validation
Do NOT change architecture decision IDs (AD-001, AD-002…)	Architecture decision IDs may be referenced by tasks and implementation agents
Respect [NEEDS CLARIFICATION] markers — only resolve with user-approved answers	Silently removing a marker hides unresolved ambiguity that may affect scope, security, or UX

Checkbox State Transitions

The only valid checkbox transitions during implementation are:

• - [ ] → - [X] (task completed, checklist item satisfied)
• Never - [X] → - [ ] (reverting completion state requires explicit user approval)
• Never delete a checkbox line entirely

Format Rules

These formats are structural contracts consumed by parsers, trackers, and cross-reference tools.

Artifact	Format	Example
Task	`- [ ] T### [P?] [US#	OBJ#?] {(FR
Requirement	`(FR	TR
Success Criterion	`SC-### [US#	OBJ#]: [Measurable, technology-agnostic outcome]`
Checklist Item	- [ ] CHK### <question> [Quality Dimension, Spec §X.Y]	- [ ] CHK001 Is the error handling strategy defined? [Completeness, Spec §3.2]
Bug Task	`- [ ] T### [BUG:severity] [RECURRING?] [ESCALATED?] [DEFERRED?] {(FR	TR

Bug task severity: CRITICAL | ERROR | WARNING. Categories: test-failure | lint-error | security-vuln | coverage-gap | requirement-gap | pi-violation | runtime-error.

Bug task modifier tags are optional and only apply to QC-generated bug work:

• [RECURRING]: a previously resolved bug regressed
• [ESCALATED]: repeated fix attempts failed and the task needs higher attention
• [DEFERRED]: excluded from the active Implement → QC loop and tracked under ## Deferred Issues

Bug tasks include blockquote context lines (not part of the task ID line):

  > Error: [actual error message, ≤200 chars]
  > Fix hint: [suggested approach]

Section Rules

These sections are structurally required — removing them breaks downstream tooling and gating.

spec.md

• Determine spec_type from frontmatter. If it is absent, treat the spec as product.
• Allowed top-level sections vary by spec_type:
  • Product: Problem Statement, Scope, User Scenarios & Testing, Requirements, Assumptions & Risks, Implementation Signals, Success Criteria, optional Glossary, optional Clarifications, optional Compliance Check
  • Technical: Problem Statement, Scope, Technical Objectives, Integration Points, Requirements, Assumptions & Risks, Implementation Signals, Success Criteria, optional Glossary, optional Clarifications, optional Compliance Check
  • Operational: Problem Statement, Scope, Operational Objectives, Integration Points, Requirements, Assumptions & Risks, Implementation Signals, Success Criteria, optional Glossary, optional Clarifications, optional Compliance Check
• Mandatory sections must remain even if empty for the active spec_type.

plan.md

• Do NOT remove the Instructions Check section — it is a gating checkpoint that must be present and evaluated
• Do NOT remove the Technical Context metadata block
• Do NOT remove the Requirement Coverage Map section — it is the primary input for task generation
• Do NOT change Architecture Decision IDs (AD-###) — they may be referenced by tasks
• Size budget: ≤ 10KB

tasks.md

• Do NOT remove the Dependencies section — it defines the phase graph that implementation agents traverse
• Do NOT remove phase headers that exist — they delineate execution boundaries. Optional empty phases may be omitted at generation time, but present phase headers must be preserved.

checklist files

• Do NOT remove or renumber CHK### items — external references depend on stable IDs
• Do NOT change the quality dimension tags in square brackets

qc-report.md

• On re-runs, the prior report is overwritten with the new report. If run history is needed, the agent should note the prior verdict in the "Re-run detection" step of the QC workflow.
• Do NOT manually edit qc-report.md — it is generated exclusively by /sddp-qc
• The report structure must follow the template at .github/skills/quality-control/assets/qc-report-template.md

manual-test.md

• Generated conditionally by /sddp-qc when manual verification is required
• May be updated on re-runs if new manual test scenarios are detected
• Do NOT remove existing test scenarios on re-run — append new ones or update existing entries

.completed / .qc-passed markers

• These are gating markers managed exclusively by /sddp-implement and /sddp-qc
• Do NOT manually create, delete, or edit these files
• .completed is deleted by QC on failure and recreated by a successful implementation re-run
• .qc-passed is created by QC on success and overwritten on subsequent passes

When These Rules Apply

These rules are active whenever an agent:

1. Edits any .md file inside a specs/ feature directory
2. Runs a workflow that modifies spec artifacts (specify, clarify, plan, tasks, implement, analyze)
3. Performs remediation on analysis findings

Violation Severity

Violations of these rules during /sddp-analyze are classified as:

Violation	Severity
Changed or removed a cross-referenced ID (T###, FR-###, TR-###, OR-###, RR-###, SC-###, CHK###, AD-###)	CRITICAL
Reordered user story or objective priorities without approval	CRITICAL
Removed a required section (Instructions Check, Dependencies)	CRITICAL
Silently removed [NEEDS CLARIFICATION] marker	HIGH
Reversed checkbox state ([X] → [ ]) without approval	HIGH
Added unauthorized top-level section to spec.md	MEDIUM
Format deviation from structural contracts	MEDIUM