Context and request
Automated and agentic work is now a first-class contributor across the MSX ecosystem, but there is no written contract for how the defects it produces are captured and tracked. When an agent's change introduces a fault — or an agent notices a defect while doing something else — that knowledge must not stay in a session log or a chat message; it must become durable, tracked work that surfaces and gets corrected like any other defect.
The MSX AGENTS directive already says "If you find a problem, fix it if it's small; otherwise, register it as an issue," and the Bug type already exists. What is missing is a spec that makes defect tracking a required, verifiable behaviour of automated/agentic work: what must be recorded, when, where, and to what standard, so a human or another agent can trust that defects are not silently lost.
This PBI delivers that spec (and, where the ecosystem provides tooling, its design) in MSXOrg/docs, which owns specs and designs.
Outcome
A durable spec exists stating that automated/agentic work MUST track the defects it creates or discovers, expressed in evergreen, technology-agnostic language following Spec-Driven Development and the Documentation Model.
In scope
- A spec capturing the need, users/jobs, requirements (
FR#/NFR#), and acceptance criteria for defect tracking by automated/agentic work.
- How a discovered or self-introduced defect becomes a tracked Bug with enough context to act on, and how the "fix-if-small, else register" rule is made verifiable.
- Where the spec lives in the docs structure and how it relates to existing Ways of Working (Agentic Development, Issues, Definition of Ready and Done).
Out of scope
- Any specific agent, model, or vendor implementation.
- Changing the Bug issue type itself.
- Non-defect telemetry (general observability), except where it references defect capture.
Aggregate acceptance criteria
- Given an agent introduces or discovers a defect, when its work completes, then the defect is recorded as durable, tracked work rather than left only in session or chat history.
- Given the spec, when a reviewer reads it, then the obligations are stated with BCP 14 keywords and each requirement has at least one observable acceptance criterion.
- Given the spec is published, then it is reachable from the relevant Ways of Working index and does not duplicate the Bug type page.
Constraints and dependencies
Technical decisions
Decomposition and placement (spec page vs. a dedicated capability folder, and whether a design is warranted) are decided during delivery and captured in the child issues. This issue owns the combined outcome, not the child-local choices.
Raised from a Platform deployment-capability session while separating "how we deploy" from "how automated work is held accountable for its defects."
Context and request
Automated and agentic work is now a first-class contributor across the MSX ecosystem, but there is no written contract for how the defects it produces are captured and tracked. When an agent's change introduces a fault — or an agent notices a defect while doing something else — that knowledge must not stay in a session log or a chat message; it must become durable, tracked work that surfaces and gets corrected like any other defect.
The MSX AGENTS directive already says "If you find a problem, fix it if it's small; otherwise, register it as an issue," and the Bug type already exists. What is missing is a spec that makes defect tracking a required, verifiable behaviour of automated/agentic work: what must be recorded, when, where, and to what standard, so a human or another agent can trust that defects are not silently lost.
This PBI delivers that spec (and, where the ecosystem provides tooling, its design) in
MSXOrg/docs, which owns specs and designs.Outcome
A durable spec exists stating that automated/agentic work MUST track the defects it creates or discovers, expressed in evergreen, technology-agnostic language following Spec-Driven Development and the Documentation Model.
In scope
FR#/NFR#), and acceptance criteria for defect tracking by automated/agentic work.Out of scope
Aggregate acceptance criteria
Constraints and dependencies
Technical decisions
Decomposition and placement (spec page vs. a dedicated capability folder, and whether a design is warranted) are decided during delivery and captured in the child issues. This issue owns the combined outcome, not the child-local choices.
Raised from a Platform deployment-capability session while separating "how we deploy" from "how automated work is held accountable for its defects."