tegwick
3008d9e2f0
Add Intake Definition of Comprehension and work-item Definition of Ready as hub policies with dashboard edit surfaces, document the Definition family and DoX-Ok/Failed badge convention, and mark STATE-WP-0076 finished.
95 lines
4 KiB
Markdown
95 lines
4 KiB
Markdown
# Intake Definition of Comprehension (DoC)
|
|
|
|
**applies_to:** `intake`
|
|
**Assessment outcomes:** `unassessed` | `DoC-Ok` | `DoC-Failed`
|
|
**Does not apply to:** workplan, task, decision, engagement, register-entry
|
|
|
|
An intake is a **discovery** work record (a find / spark). **DoC** is the quality
|
|
policy for “we understand this demand or signal well enough to route or promote.”
|
|
It is **not** implementation design and **not** Definition of Ready.
|
|
|
|
Lifecycle `status` (open / vetted / routed / closed) is independent of DoC
|
|
assessment. Prefer: treat **DoC-Ok** as the quality bar before confident
|
|
`vetted` → `routed` → promote. Process may still move without DoC-Ok; that is
|
|
quality debt, not forbidden.
|
|
|
|
Related:
|
|
|
|
- Work-record umbrella: `dashboard/src/docs/work-records.md`
|
|
- Quality model: `docs/work-record-quality-gates.md`
|
|
- Delivery readiness: `policies/work-item-dor.md` (DoR)
|
|
- Intake reference: `dashboard/src/docs/intakes.md`
|
|
|
|
---
|
|
|
|
## Core checklist (all intakes)
|
|
|
|
An intake may be assessed **DoC-Ok** when all of the following hold:
|
|
|
|
- [ ] **Signal stated** — title (and description if non-obvious) says what was
|
|
observed, asked, or found, not a vague “look into X.”
|
|
- [ ] **Why it matters** — at least one sentence of consequence if ignored
|
|
(risk, opportunity, blocker, cost of delay).
|
|
- [ ] **Known unknowns listed** — what we do *not* know yet (owner, repo, scope,
|
|
feasibility, counterparty intent, …), or an explicit “no material unknowns.”
|
|
- [ ] **Provisional ownership** — at least one of: `topic_id` / `workplan_id` /
|
|
`repo_id` / domain hypothesis — **or** an explicit statement that ownership is
|
|
still unknown and who will decide.
|
|
- [ ] **Next action** — one of: route, promote (to which kind if known), decline,
|
|
absorb, or “needs more discovery” with a named follow-up.
|
|
- [ ] **Not a premature workplan** — the intake does not pretend to be a full
|
|
task breakdown, DoD, or implementation design (those belong after promotion
|
|
under DoR).
|
|
|
|
If any core item fails after assessment, record **DoC-Failed** and note the gap.
|
|
|
|
---
|
|
|
|
## Outside-originated profile
|
|
|
|
Use this section when the signal is **external** or **structurally sparse**:
|
|
external demand into the fleet, true third-party/upstream, mail/founder note
|
|
without repo context, or `origin` / tags such as `external-demand` /
|
|
`third-party`.
|
|
|
|
Additional criteria for **DoC-Ok** (on top of the core checklist):
|
|
|
|
- [ ] **Source of signal** — `origin` and, when available, `origin_ref` (or
|
|
equivalent note) identify where the demand came from.
|
|
- [ ] **Boundary named** — one of: *ecosystem* (another fleet repo), *true
|
|
third-party*, *external demand into us*, or *unknown* with a plan to classify.
|
|
- [ ] **No invented foreign structure** — we do not schedule *their* backlog as
|
|
our workplan graph; we only record *our* understanding and *our* possible
|
|
response.
|
|
- [ ] **Enough context to avoid premature promote** — promoting to task/workplan
|
|
would not require guessing the owning repo or outcome shape; if it would,
|
|
keep the intake open/vetted and list the missing facts under known unknowns.
|
|
- [ ] **Counterparty or channel** (when third-party or external) — who/what is
|
|
outside, even if only “unknown maintainer of package X.”
|
|
|
|
Ecosystem-only signals (work for another registered repo) usually need routing
|
|
clarity, not the full third-party bar; still record boundary as ecosystem.
|
|
|
|
---
|
|
|
|
## Assessment practice (convention)
|
|
|
|
- Assessors: owning agent, domain owner, or human operator.
|
|
- Record outcome in a note, progress event, or later frontmatter/badge field:
|
|
`DoC-Ok` or `DoC-Failed` plus date and short reason if failed.
|
|
- Re-assess after material new information; a prior DoC-Ok can become Failed or
|
|
be superseded by a new Ok.
|
|
- **DoC-Ok does not authorize implementation** — only comprehension for
|
|
routing/promotion. Delivery readiness is **DoR** on the resulting task or
|
|
workplan.
|
|
|
|
---
|
|
|
|
## Explicit non-requirements
|
|
|
|
DoC does **not** require:
|
|
|
|
- Task breakdown, estimates, or acceptance tests
|
|
- Full solution design
|
|
- DoR or DoD criteria
|
|
- A workplan file to already exist
|