130 lines
5.4 KiB
Markdown
130 lines
5.4 KiB
Markdown
|
# Definition of Ready (DoR)
|
|||
|
|
|
|||
|
|
**Policy key:** `work-item-dor`
|
|||
|
|
**applies_to:** `task`, `workplan` (separate sections below)
|
|||
|
|
**Assessment outcomes:** `unassessed` | `DoR-Ok` | `DoR-Failed`
|
|||
|
|
**Does not apply to:** intake (use DoC), decision, engagement (no DoR yet)
|
|||
|
|
|
|||
|
|
**DoR** is the quality policy for **implementation-readiness** of delivery
|
|||
|
|
records. “Work-item” in the policy name means the **delivery side** of the
|
|||
|
|
work-record framework (executable units and their plans). In body text:
|
|||
|
|
|
|||
|
|
- **task** = unit work-item
|
|||
|
|
- **workplan** = structure (collection/plan over tasks), **not** “a large task”
|
|||
|
|
|
|||
|
|
Lifecycle `status` is independent of DoR assessment:
|
|||
|
|
|
|||
|
|
- Workplan `status=ready` is a process claim; **DoR-Ok** means this checklist
|
|||
|
|
passed when last assessed.
|
|||
|
|
- A workplan may be `ready` or `active` without DoR-Ok (quality debt).
|
|||
|
|
- A task may enter `progress` without DoR-Ok; that is allowed but discouraged
|
|||
|
|
for non-trivial work.
|
|||
|
|
|
|||
|
|
Related:
|
|||
|
|
|
|||
|
|
- Comprehension (discovery): `policies/intake-doc.md` (DoC)
|
|||
|
|
- Completion: `policies/workstream-dod.md` (DoD; exit companion)
|
|||
|
|
- Model: `docs/work-record-quality-gates.md`
|
|||
|
|
- Lifecycle: `dashboard/src/docs/workstream-lifecycle.md`
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Shared criteria (task and workplan)
|
|||
|
|
|
|||
|
|
For **DoR-Ok**, the following always hold (kind sections add specifics):
|
|||
|
|
|
|||
|
|
- [ ] **Outcome or done-condition** — what “good enough to stop” looks like, or
|
|||
|
|
an explicit pointer to DoD / acceptance criteria.
|
|||
|
|
- [ ] **Scope in / out** — what is included and what is explicitly out of scope
|
|||
|
|
(or “no material out-of-scope items”).
|
|||
|
|
- [ ] **Owning repo** — delivery repo is known and matches ADR-001 anchoring
|
|||
|
|
(or the task’s parent workplan repo).
|
|||
|
|
- [ ] **Who executes** — owner/assignee or named agent role is clear enough to
|
|||
|
|
start.
|
|||
|
|
- [ ] **Dependencies / blockers** — known dependencies listed, or an explicit
|
|||
|
|
“none.” Unresolved hard blockers mean DoR-Failed until cleared or redesigned.
|
|||
|
|
- [ ] **Verification signal** — how we will know it worked (test, check,
|
|||
|
|
manual verification note, or “N/A: pure docs” with reason).
|
|||
|
|
- [ ] **Lane / autonomy** — lane is set or inherited where the record supports
|
|||
|
|
it; red/yellow work has human expectation stated if required by autonomy
|
|||
|
|
policy.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Section: task (`kind: task`)
|
|||
|
|
|
|||
|
|
Additional **DoR-Ok** criteria for a task:
|
|||
|
|
|
|||
|
|
- [ ] **Parent workplan** — task is attached to a workplan (or today’s ADHOC
|
|||
|
|
workplan) so execution context is not free-floating.
|
|||
|
|
- [ ] **Actionable title** — describes a completable unit, not a multi-week
|
|||
|
|
program (programs belong in a workplan with multiple tasks).
|
|||
|
|
- [ ] **Status intent** — starting `progress` is justified (not blocked on
|
|||
|
|
missing input that should keep the task in `wait`).
|
|||
|
|
|
|||
|
|
Tasks that are pure residual cleanup may be thin; still state done-condition
|
|||
|
|
and verification, even if one line each.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Section: workplan (`kind: workplan`)
|
|||
|
|
|
|||
|
|
Additional **DoR-Ok** criteria for a workplan:
|
|||
|
|
|
|||
|
|
- [ ] **Goal** — one paragraph (or equivalent) for why this plan exists.
|
|||
|
|
- [ ] **Task decomposition** — open work is broken into tasks, or an explicit
|
|||
|
|
note that the first task is “decompose further” with a bound.
|
|||
|
|
- [ ] **Review vs execute** — if `status=ready`, review metadata is present when
|
|||
|
|
the plan claims repo-state review (`reviewed_at` / `reviewed_against_commit`
|
|||
|
|
or equivalent narrative). Missing review metadata ⇒ prefer DoR-Failed for a
|
|||
|
|
`ready` claim, or leave unassessed.
|
|||
|
|
- [ ] **Structure role respected** — the plan does not substitute for missing
|
|||
|
|
DoC on a vague external spark; if the plan was promoted from intake, origin
|
|||
|
|
link is present when available (`origin: intake:…`).
|
|||
|
|
|
|||
|
|
Workplan **DoR-Ok** does not require all child tasks to be DoR-Ok; it requires
|
|||
|
|
the plan itself to be ready to *run as a structure*. Child tasks should be
|
|||
|
|
assessed when they are about to be executed.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Outside-originated profile
|
|||
|
|
|
|||
|
|
When the work-item or plan came from outside structural knowledge (promoted
|
|||
|
|
intake with external origin, third-party response work, external demand):
|
|||
|
|
|
|||
|
|
- [ ] **Origin link** — `origin` / `origin_ref` or intake id / progress note
|
|||
|
|
ties back to the discovery record.
|
|||
|
|
- [ ] **Boundary decision recorded** — ecosystem vs true third-party vs
|
|||
|
|
external demand into us.
|
|||
|
|
- [ ] **Our work only** — scope describes *our* deliverable (patch, adapter,
|
|||
|
|
doc, decision), not control of an external backlog.
|
|||
|
|
- [ ] **External reference** — issue/PR/URL or “none yet” with reason, when
|
|||
|
|
third-party interaction is in scope.
|
|||
|
|
- [ ] **Residual unknowns** — still-open external uncertainties listed; none
|
|||
|
|
that would make the first implementation step pure guesswork.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Relationship to DoD and lifecycle
|
|||
|
|
|
|||
|
|
| Gate | When | Policy |
|
|||
|
|
|------|------|--------|
|
|||
|
|
| DoC | Discovery understood | `intake-doc` |
|
|||
|
|
| DoR | Ready to implement | this file |
|
|||
|
|
| DoD | Quality-complete when finishing | `workstream-dod` |
|
|||
|
|
|
|||
|
|
Finishing a workplan (`status=finished`) without **DoD-Ok** is allowed; treat
|
|||
|
|
as quality debt. Prefer DoR-Ok before heavy implementation; prefer DoD-Ok before
|
|||
|
|
calling the outcome high-quality complete.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Assessment practice (convention)
|
|||
|
|
|
|||
|
|
- Assessors: workplan owner, executing agent, or human operator.
|
|||
|
|
- Record `DoR-Ok` or `DoR-Failed` with date and failed criteria if any.
|
|||
|
|
- Re-assess after major scope change; stale DoR-Ok after large context shift
|
|||
|
|
should be treated as unassessed or re-checked.
|
|||
|
|
- Enforcement is convention only (STATE-WP-0076); no API hard-block.
|