feat: ship DoC and DoR quality policies (STATE-WP-0076)

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.

policies/intake-doc.md

@@ -0,0 +1,95 @@
+# 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

policies/work-item-dor.md

@@ -0,0 +1,129 @@
+# 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.