coulomb/state-hub
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

docs: work-record consolidation references and STATE-WP-0076 ready
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
Details
CI Smoke / container-smoke (push) Successful in 2s
Details

Browse source 
Align dashboard reference pages with intake-as-discovery and suggestions as
legacy, frame work records as unit vs structure artefacts, and add the ready
STATE-WP-0076 plan for DoC/DoR quality policies. Include generated work-record
index and recent legacy-meter evidence captures.
This commit is contained in:
tegwick 2026-07-22 19:56:27 +02:00
parent 21d576c96f
commit d8a2bb5c6b
15 changed files with 5951 additions and 103 deletions
Download patch file Download diff file Expand all files Collapse all files

6
dashboard/observablehq.config.js
View file

@ -83,7 +83,7 @@ export default {
{ name: "Interventions", path: "/interventions" },
{ name: "Tasks", path: "/tasks" },
{ name: "UI Feedback", path: "/ui-feedback" },
{ name: "Suggestions", path: "/suggestions" },
{ name: "Suggestions (legacy)", path: "/suggestions" },
{ name: "WSJF Triage", path: "/wsjf-triage" },
],
},
@ -104,6 +104,7 @@ export default {
{ name: "Domains", path: "/docs/domains" },
{ name: "Goals", path: "/docs/goals" },
{ name: "Extension Points", path: "/docs/extensions" },
{ name: "Intakes", path: "/docs/intakes" },
{ name: "Inter-Repo Communication", path: "/docs/inter-repo-communication" },
{ name: "Interventions", path: "/docs/interventions" },
{ name: "Live Data", path: "/docs/live-data" },
@ -117,15 +118,16 @@ export default {
{ name: "SBOM", path: "/docs/sbom" },
{ name: "SCOPE.md", path: "/docs/scope" },
{ name: "Service Catalog", path: "/docs/services" },
{ name: "Suggestions (legacy)", path: "/docs/suggestions" },
{ name: "Tasks", path: "/docs/tasks" },
{ name: "TPSC", path: "/docs/tpsc" },
{ name: "TPSC — GDPR Maturity", path: "/docs/gdpr-maturity" },
{ name: "Technical Debt", path: "/docs/debt" },
{ name: "Todo", path: "/docs/todo" },
{ name: "Work Records", path: "/docs/work-records" },
{ name: "Workplan Health", path: "/docs/workstream-health-index" },
{ name: "Workplan Lifecycle", path: "/docs/workstream-lifecycle" },
{ name: "Workplans", path: "/docs/workstreams" },
{ name: "Suggestions", path: "/docs/suggestions" },
{ name: "WSJF Triage", path: "/docs/wsjf-triage" },
],
},

11
dashboard/src/docs/capabilities.md
View file

@ -227,8 +227,9 @@ and age in days.
---
*Capability requests are a sanctioned write use case of the State Hub alongside
`resolve_decision`, `get_next_steps`, and the suggestion backlog writes
(`create_suggestion`, `vet_suggestion`, `decline_suggestion`,
`promote_suggestion_to_task`, `bump_suggestion_relevance`). They do not
originate in workplan files —
they are operational coordination.*
`resolve_decision`, `get_next_steps`, and intake capture (`create_intake`,
`route_intake`, `close_intake`; promotion via `statehub promote-intake`). The
legacy suggestion mutation tools (`create_suggestion`, `vet_suggestion`, …)
return HTTP 410. Capability requests do not originate in workplan files —
they are operational coordination. See [Work Records](/docs/work-records) and
[Intakes](/docs/intakes).*

114
dashboard/src/docs/contributions.md
View file

@ -4,10 +4,16 @@ title: Contributions — Reference
# Contributions — Reference
Contributions track **outbound upstream work** — things the Custodian has
identified that belong in a repo it does not own or control. Each contribution
is a structured artifact filed locally in the repo's `contrib/` directory and
registered in the state hub so it is never lost.
Contributions track **outbound upstream work** — things identified for a
repository the fleet does not own or control. Each contribution is a
structured artifact filed locally under `contrib/` and registered in State Hub
so it is not lost.
Contributions are **not** a work-record kind in the fleet registry
(`work-record-types_v0.1.md`). They are a separate hub entity and dashboard
surface used for third-party coordination. Work-record kinds cover internal
coordination (workplan, task, intake, decision, engagement, register-entry).
See [Work Records](/docs/work-records).
---
@ -15,22 +21,26 @@ registered in the state hub so it is never lost.
| Type | Full name | Use when |
|------|-----------|----------|
| `br` | Bug Report | You found a defect in an upstream tool or library |
| `fr` | Feature Request | You need functionality that upstream does not yet provide |
| `ep` | Extension Point | You identified a future enhancement opportunity in upstream code |
| `upr` | Upstream PR | You have written (or are writing) a patch for an upstream repo |
| `br` | Bug Report | Defect in an upstream tool or library |
| `fr` | Feature Request | Functionality upstream does not yet provide |
| `ep` | Extension Point | Future enhancement opportunity in upstream code |
| `upr` | Upstream PR | Patch written (or being written) for an upstream repo |
---
## Flow workstations
## Lifecycle (workstations)
```
Contribution status is evaluated by the task-flow engine
(`flows/contribution.yaml`). The stored field is `status`; flow tooling may
call the same value a **workstation**.
```text
draft → submitted → acknowledged → accepted → merged
↘ ↘
rejected withdrawn
```
| Workstation | Meaning |
| Status | Meaning |
|--------|---------|
| **draft** | Artifact written locally; not yet sent upstream |
| **submitted** | Filed as a GitHub issue, PR, or email — awaiting upstream response |
@ -40,36 +50,42 @@ draft → submitted → acknowledged → accepted → merged
| **rejected** | Upstream declined; record kept for future reference |
| **withdrawn** | We decided not to pursue it |
Contribution movement is evaluated by the task-flow engine. The API asks
whether the target workstation is reachable from the current information
object; if not, it returns structured blocking assertions instead of a generic
"transition not allowed" message. `submitted_at` is stamped automatically when
the contribution reaches `submitted`; `resolved_at` is stamped when it reaches
`merged`, `rejected`, or `withdrawn`.
Reachability is assertion-based. For example, `rejected` is only enterable from
`submitted` or `acknowledged`; `merged` only from `accepted`. If a target is
not reachable, the API returns structured blocking assertions rather than a
generic “transition not allowed” message.
Timestamps: `submitted_at` is stamped when status becomes `submitted`;
`resolved_at` is stamped when status becomes `merged`, `rejected`, or
`withdrawn` (and related terminal paths as implemented on the status patch).
---
## Relation to the Todo classification
Contributions map directly to the **Third-party** class in the inter-repo
communication taxonomy:
Contributions map to the **Third-party** class in the inter-repo communication
taxonomy:
| Todo class | Mechanism |
|------------|-----------|
| Internal | Workplan file + task in this repo's workplan |
| Internal | Workplan file + task in this repo |
| Ecosystem | State hub task with `[repo:<slug>]` prefix |
| **Third-party** | **Contribution artifact in `contrib/` + state hub registration** |
| **Third-party** | **Contribution artifact in `contrib/` + hub registration** |
Contributions in `draft`, `submitted`, or `acknowledged` workstations appear as
open Third-party todos on the [Todo](/todo) page.
Open third-party items are contributions in `draft`, `submitted`, or
`acknowledged`. They appear on the [Todo](/todo) page until the upstream loop
closes (`merged`, `rejected`, or `withdrawn`).
Intakes are **not** third-party contributions: an intake is internal capture of
a spark; a contribution is outbound work aimed at someone else’s repo.
---
## File layout
Each artifact lives in the current repo under `contrib/`:
Each artifact lives in the **current** repo under `contrib/`:
```
```text
contrib/
bug-reports/ br-YYYY-MM-DD--<org>--<repo>--<slug>.md
feature-requests/ fr-YYYY-MM-DD--<org>--<repo>--<slug>.md
@ -77,8 +93,8 @@ contrib/
upstream-prs/ upr-YYYY-MM-DD--<org>--<repo>--<slug>.md
```
Templates live in `~/the-custodian/canon/standards/contrib-templates/`.
Convention details: `~/the-custodian/canon/standards/contribution-convention_v0.1.md`.
Templates: `~/the-custodian/canon/standards/contrib-templates/`.
Convention: `~/the-custodian/canon/standards/contribution-convention_v0.1.md`.
---
@ -86,38 +102,52 @@ Convention details: `~/the-custodian/canon/standards/contribution-convention_v0.
**1. Write the artifact file** using the appropriate template.
**2. Register it in the state hub** via MCP:
**2. Register it in the state hub** (MCP):
```
```text
register_contribution(
type = "fr",
title = "Add sidebar TOC injection API",
target_org = "observablehq",
target_repo = "framework",
body_path = "contrib/feature-requests/fr-2026-02-26--observablehq--framework--toc.md",
related_workstream_id = "<uuid>"
type = "fr",
title = "Add sidebar TOC injection API",
target_org = "observablehq",
target_repo = "framework",
body_path = "contrib/feature-requests/fr-2026-02-26--observablehq--framework--toc.md",
related_workplan_id = "<uuid>" # preferred; related_workstream_id still accepted as alias
)
```
**3. Close the loop** when you file it upstream:
REST: `POST /contributions/` with the same fields.
```
**3. Close the loop** when filed upstream — advance via flow tooling or status
patch:
```text
advance_workstation(entity_type="contribution", entity_id="<uuid>", target_workstation="submitted")
```
**4. Keep updating** as upstream responds — `acknowledged`, `accepted`, `merged`.
```bash
curl -X PATCH "http://127.0.0.1:8000/contributions/<uuid>/status" \
-H "Content-Type: application/json" \
-d '{"status": "submitted"}'
```
**4. Keep updating** as upstream responds — `acknowledged`, `accepted`,
`merged` (or `rejected` / `withdrawn`).
Optional links: `related_topic_id`, `related_workplan_id`, `repo_id` (managed
repo that owns the local artifact).
---
## Kanban board
The Contributions page groups artifacts by status column. Only columns with at
least one entry are shown. The **⚠ follow-up banner** appears when any
least one entry are shown. The **follow-up banner** appears when any
contribution has been in `submitted` or `acknowledged` for an extended period
without further movement — a prompt to check in with upstream.
Data source: `GET /contributions/`.
---
*Contributions are append-only. Rejected or withdrawn artifacts are retained as
institutional memory — they explain why certain approaches were tried and
dropped.*
*Contributions are retained after rejection or withdrawal — institutional
memory for why certain approaches were tried and dropped.*

91
dashboard/src/docs/suggestions.md
View file

@ -1,9 +1,44 @@
# Demand-Weighted Suggestion Backlog
---
title: Suggestions (legacy) — Reference
---
The `/suggestions` page shows persisted **gated needs** that are not yet real
tasks. Each unmet lookup increments `relevance`, which raises WSJF ranking.
# Suggestions (legacy) — Reference
## Stages
The **suggestion** entity is **read-only legacy**. It predates the fleet
**work-record** model. Gated needs, findings, and unvetted sparks are recorded
as **intake** work records (`kind: intake`), not as suggestions.
| Use | Path |
|-----|------|
| **Current** | [Intakes](/docs/intakes) · `POST /intakes/` · MCP `create_intake` |
| **Canon** | `the-custodian/canon/standards/work-record-types_v0.1.md` |
| **Legacy table** | `GET /suggestions/` (historical rows may remain) |
Umbrella: [Work Records](/docs/work-records).
---
## What still exists
| Surface | Behaviour today |
|---------|-----------------|
| `GET /suggestions/` | Lists historical suggestion rows (if any). Ranking query params still exist on the read path. |
| `GET /suggestions/{id}` | Read one historical row. |
| Mutation routes (`POST /suggestions/`, vet, decline, promote, bump-relevance) | **HTTP 410 Gone** — body points at `/intakes/` and the work-record standard |
| MCP `create_suggestion`, `vet_suggestion`, `decline_suggestion`, `promote_suggestion_to_task`, `bump_suggestion_relevance` | Call the retired mutation endpoints; they return 410 |
| Dashboard **Suggestions** page | Still polls `GET /suggestions/?rank=wsjf`; useful only for residual history |
| `GET /state/summary` → `ranked_suggestions` | Still computed from open suggestion rows; after migration the open set is typically empty |
Records were not deleted at retirement. Open backlog at cut-over (2026-07-21,
CUST-WP-0061-T06) was re-authored as file-backed intakes (with
`origin: legacy-suggestion:<uuid>`) and the hub suggestion rows were closed in
place so history remained inspectable.
---
## Former stage model (historical)
While mutations were live, stages were:
| Stage | Meaning |
|-------|---------|
@ -12,38 +47,34 @@ tasks. Each unmet lookup increments `relevance`, which raises WSJF ranking.
| `promoted` | Became a real `Task` (`promoted_task_id` set) |
| `declined` | Rejected; terminal |
## WSJF projection
WSJF ranking used `base_value`, `relevance`, `job_size`, and
`relevance_weight`. That ranking applied only to the suggestion table; it is
not the intake ranking model.
```text
cost_of_delay = base_value + (relevance_weight × relevance)
wsjf = cost_of_delay / job_size
```
---
`GET /suggestions?rank=wsjf` returns open suggestions/requirements ordered by
score. Promoted and declined entries are excluded unless
`include_terminal=true`.
## Mapping to intake
## Sanctioned writes
| Suggestion concept | Intake equivalent |
|--------------------|-------------------|
| Create gated need | `POST /intakes/` / `create_intake` |
| Vet | Move toward `vetted` / notes on the intake |
| Promote to task | `route_intake` then `statehub promote-intake … --to task` (or workplan / decision / engagement) |
| Decline | `close_intake(outcome="declined")` |
| Absorbed by existing work | `close_intake(outcome="absorbed")` |
| Domain-scoped row | Intake scoped by `topic_id` and/or `workplan_id` and/or `repo_id` |
MCP and REST:
Do not open new work through the suggestion API.
- `create_suggestion` / `POST /suggestions/`
- `vet_suggestion` / `POST /suggestions/{id}/vet`
- `decline_suggestion` / `POST /suggestions/{id}/decline`
- `promote_suggestion_to_task` / `POST /suggestions/{id}/promote`
- `bump_suggestion_relevance` / `POST /suggestions/{id}/bump-relevance`
---
Relevance also bumps automatically when:
## Related pages
- `GET /state/next_steps` surfaces open suggestions
- A `CapabilityRequest` matches an open suggestion
- [Intakes](/docs/intakes) — current entity and lifecycle
- [Work Records](/docs/work-records) — kind registry
- [WSJF Triage](/docs/wsjf-triage) — daily advisory triage (workplan-oriented)
## Daily triage
---
`GET /state/summary` includes `ranked_suggestions` for the activity-core
`daily_triage_digest` resolver. See [WSJF Triage](/docs/wsjf-triage).
## Origin
Motivated by ops-warden `WARDEN-WP-0012` gated routing scenarios. Example
backfill: `scripts/seed_wp0012_suggestions.py`.
*Suggestion mutations are retired by design (CUST-WP-0061). Intake is a fresh
entity, not a rename of the suggestions table.*

7
dashboard/src/docs/tasks.md
View file

@ -8,12 +8,15 @@ The Tasks page shows all tasks across every workplan and domain, with live
filtering, a workstation distribution chart, and a waiting-tasks highlight
section.
A **task** is a work-record kind: the smallest executable unit. Tasks always
belong to a workplan. Umbrella: [Work Records](/docs/work-records).
---
## Task workstations
Tasks still expose their current workstation through the `status` field for API
compatibility.
Tasks expose their current lifecycle position through the `status` field (flow
tooling may call that position a workstation).
| Workstation | Meaning |
|--------|---------|

73
dashboard/src/docs/work-records.md
View file

@ -4,10 +4,12 @@ title: Work Records — Reference
# Work Records — Reference
A **work record** is any identified, lifecycle-bearing coordination artefact
indexed by State Hub. Workplans and tasks are work records; so are intakes,
decisions, engagements, and register entries. The term is the shared umbrella
for planning, execution, and coordination — not a separate product surface.
A **work record** is any identified, lifecycle-bearing **coordination artefact**
indexed by State Hub. The term is intentionally **generic**: the same
framework covers individual units of work or discovery, **collections and
plans**, and related artefacts (decisions, engagements, register entries). It
is a mode of organising coordination — not a single product page and not a
synonym for “task.”
Fleet canon (normative):
`the-custodian/canon/standards/work-record-types_v0.1.md` and the machine
@ -16,16 +18,36 @@ implements and exposes today.
---
## Units and structure
Kinds share one spine and registry, but they play different **roles**:
| Role | What it is | Kinds today | Everyday gloss |
|------|------------|-------------|----------------|
| **Unit** | A single coordination atom | `task`, `intake`, `decision`, `engagement`, many `register-entry` rows | work-item (task); find / spark (intake) |
| **Structure** | A collection or plan with relations | `workplan` | delivery plan over tasks (and dependencies between plans) |
A **workplan is a work record** in the mechanical sense (id, status, hub index).
It is **not** a large task: it is **structure** over unit records. Calling both
“work records” means they use the same identity and reconciliation machinery,
not that they feel the same in day-to-day language.
Generated views (for example a per-repo work-record index, or a future
“discovery map” over intakes) organise records **without** needing a new kind
until a real aggregate must be owned as its own artefact.
---
## Kind registry (closed list)
| Kind | Id scheme (typical) | Meaning in State Hub today |
|------|---------------------|----------------------------|
| **workplan** | `{PREFIX}-WP-NNNN` | Structured, dependency-bearing body of work; file under `workplans/` (ADR-001) |
| **task** | `{WP-ID}-TNN` · `ADHOC-YYYY-MM-DD-TNN` | Smallest executable unit; lives in a workplan file |
| **intake** | `{PREFIX}-IN-NNNN` | Spark: idea, finding, directive, or request before it is a plan/task |
| **decision** | `{PREFIX}-DEC-YYYY-NNN` (file) · hub decision entity | Approval package / recorded choice |
| **engagement** | `{PREFIX}-ENG-YYYY-NNN` | Scheduled external interaction (file-backed; hub entity not yet first-class) |
| **register-entry** | `RISK-…`, `TD-…`, `CAP-…`, `CCR-…`, `ADR-…` | Risks, debt, capability requests, credential change requests, ADRs |
| Kind | Role | Id scheme (typical) | Meaning in State Hub today |
|------|------|---------------------|----------------------------|
| **workplan** | structure | `{PREFIX}-WP-NNNN` | Dependency-bearing plan; file under `workplans/` (ADR-001) |
| **task** | unit | `{WP-ID}-TNN` · `ADHOC-YYYY-MM-DD-TNN` | Smallest executable delivery unit; lives in a workplan file |
| **intake** | unit | `{PREFIX}-IN-NNNN` | Discovery spark: idea, finding, directive, or request |
| **decision** | unit | `{PREFIX}-DEC-YYYY-NNN` (file) · hub decision entity | Approval package / recorded choice |
| **engagement** | unit | `{PREFIX}-ENG-YYYY-NNN` | Scheduled external interaction (file-backed; hub entity not yet first-class) |
| **register-entry** | unit (mostly) | `RISK-…`, `TD-…`, `CAP-…`, `CCR-…`, `ADR-…` | Risks, debt, capability requests, credential change requests, ADRs |
Unregistered id patterns are rejected by CI and `statehub fix-consistency`
(sidetrack detector). New kinds are added only via the canon registry.
@ -36,6 +58,33 @@ artifacts). They remain a separate hub entity and dashboard surface — see
---
## Lifecycle vs quality (Definition-of-X)
Two independent axes:
| Axis | Answers | Examples |
|------|---------|----------|
| **Lifecycle** (`status`) | Where is this in process? | workplan `active` / `finished`; intake `routed`; task `progress` |
| **Definition assessment** | Did it pass a named quality policy when assessed? | DoC / DoR / DoD (and DoI / DoM for repos/services) |
Assessments do **not** invent extra lifecycle states. Outcomes are:
- **unassessed** — no Definition-of-X assessment recorded yet
- **`DoX-Ok`** (tiered policies may use `DoM-Ok-1`, …) — last assessment passed
- **`DoX-Failed`** — assessment ran and failed
A workplan may be `status=finished` without **DoD-Ok**, or `status=ready`
without **DoR-Ok**. That is allowed: process can advance while quality debt
stays visible. Policies live under `policies/` (same pattern as Repository DoI
and Service DoM). **DoC** (intake) and **DoR** (task/workplan) are introduced
by workplan `STATE-WP-0076`.
Discovery quality (intake) is **not** the same as implementation-readiness
(task/workplan). Outside or sparse-context signals should be comprehended
(DoC) before they are promoted into structured delivery work.
---
## Conventional spine
Every work record carries the same conceptual fields (kind-specific fields

13
dashboard/src/docs/workstreams.md
View file

@ -4,11 +4,14 @@ title: Workplans — Reference
# Workplans — Reference
A workplan is a bounded unit of work within a topic. It carries a stored
workstation label in the `status` field, an optional owner and due date, and
belongs to exactly one project domain. The Workplans page gives you a
filtered, visual overview of active work, derived blocked state, and the
dependency graph between workplans.
A **workplan** is a work-record kind: a bounded, dependency-bearing unit of
work within a topic. It carries a stored lifecycle label in the `status`
field, an optional owner and due date, and belongs to exactly one project
domain. The Workplans page gives you a filtered, visual overview of active
work, derived blocked state, and the dependency graph between workplans.
Umbrella: [Work Records](/docs/work-records). Lifecycle detail:
[Workplan Lifecycle](/docs/workstream-lifecycle).
The [Daily WSJF Triage](/wsjf-triage) page is a companion review surface for
activity-core's daily recommendations. It links recommendation candidates back

9
dashboard/src/docs/wsjf-triage.md
View file

@ -55,3 +55,12 @@ that keep surfacing as the next best piece of work.
No write controls live on this page. It is intentionally a review page so the
daily runner remains a focus surface, not an execution loop.
## Suggestions vs intakes
The triage page and some summary digests historically linked a ranked
**suggestion** backlog. That entity is retired for writes; open gated needs
are **intake** work records. `ranked_suggestions` on the state summary still
reads the legacy suggestion table (typically empty after migration). Live
intake backlog: `GET /intakes/` — see [Intakes](/docs/intakes) and
[Suggestions (legacy)](/docs/suggestions).

6
dashboard/src/reference.md
View file

@ -21,22 +21,25 @@ convention used in the Custodian State Hub.
| Page | What it covers |
|------|---------------|
| [Connecting to the Hub](/docs/connecting) | Local and remote connection setup, ops-bridge tunnels, MCP transports |
| [Contributions](/docs/contributions) | Contribution types, lifecycle, third-party todo workflow |
| [Contributions](/docs/contributions) | Outbound third-party BR/FR/EP/UPR artifacts, lifecycle, todo class (not a work-record kind) |
| [Decision Health](/docs/decisions-kpi) | KPI formula, avg resolve time, open-age colour thresholds |
| [Decisions](/docs/decisions) | Decision types, statuses, escalation rules, filter bar |
| [Dependencies](/docs/dependencies) | Dependency edges, registration, cycle detection |
| [Domains](/docs/domains) | Domain model, statuses, cards with repos |
| [Extension Points](/docs/extensions) | EP types, statuses, priorities, registration |
| [Intakes](/docs/intakes) | Work-record kind for sparks; lifecycle, promotion, API/MCP |
| [Inter-Repo Communication](/docs/inter-repo-communication) | Boundary rule, Internal/Ecosystem/Third-party taxonomy, routing workflows |
| [Live Data](/docs/live-data) | Poll interval, live indicator states, offline recovery |
| [Overview](/docs/overview) | State summary sections, workplan chart, blocking decisions, next steps |
| [Progress Log](/docs/progress-log) | Event types, append-only policy, session protocol |
| [Repos](/docs/repos) | Repo registry, SBOM coverage map, ingestion commands |
| [SBOM](/docs/sbom) | Lockfile ingestion, licence report, copyleft detection |
| [Suggestions (legacy)](/docs/suggestions) | Retired gated-need table; pointer to intakes |
| [Tasks](/docs/tasks) | Task statuses, priorities, filter bar, status distribution chart |
| [Technical Debt](/docs/debt) | Debt types, severities, statuses, registration |
| [Todo](/docs/todo) | Internal/Ecosystem/Third-party classification, data sources |
| [Workplan Health](/docs/workstream-health-index) | WHI formula, six base metrics, per-domain breakdown |
| [Workplan Lifecycle](/docs/workstream-lifecycle) | Workplan stored states, health labels, flow operations |
| [Workplans](/docs/workstreams) | Workplan statuses, dependency edges, WHI KPI card |
| [WSJF Triage](/docs/wsjf-triage) | Daily triage reports, action vocabulary, advisory review workflow |
@ -46,6 +49,7 @@ convention used in the Custodian State Hub.
| Topic | What it covers |
|-------|---------------|
| [Work Records](/docs/work-records) | Umbrella term, kind registry, spine, lifecycles, legacy name map |
| [State Hub](/docs/state-hub) | Why/how/what — Derived Data Store principle, orchestrator role, architecture diagram, design principles |
| [TPSC](/docs/tpsc) | Third-Party Services Catalog — tpsc.yaml format, ingest, MCP tools |
| [TPSC — GDPR Maturity](/docs/gdpr-maturity) | 7-level CNIL/IAPP scale, per-level guidance, key GDPR concepts |

12
dashboard/src/suggestions.md
View file

@ -1,5 +1,5 @@
---
title: Suggestions
title: Suggestions (legacy)
---
```js
@ -30,7 +30,7 @@ const _ok = sugState.ok ?? false;
const _ts = sugState.ts;
```
# Demand-Weighted Suggestions
# Suggestions (legacy)
```js
import {injectTocTop} from "./components/toc-sidebar.js";
@ -46,8 +46,12 @@ injectTocTop("live-indicator", _liveEl);
const _h1 = document.querySelector("#observablehq-main h1");
if (_h1) { _h1.style.position = "relative"; withDocHelp(_h1, "/docs/suggestions"); }
display(html`<p class="dim">Ranked by WSJF = (base_value + relevance_weight × relevance) / job_size. Gated needs accrue relevance when unmet.</p>`);
display(html`<p class="dim"><a href="/wsjf-triage">Daily WSJF triage</a> consumes this backlog in its digest.</p>`);
display(html`<p class="dim"><strong>Read-only legacy.</strong> New gated needs are <em>intake</em> work records
(<code>GET /intakes/</code>, MCP <code>create_intake</code>) — see
<a href="/docs/intakes">Intakes</a> and <a href="/docs/suggestions">Suggestions reference</a>.
This page lists historical <code>GET /suggestions/</code> rows only; mutations return HTTP 410.</p>`);
display(html`<p class="dim">Former ranking: WSJF = (base_value + relevance_weight × relevance) / job_size.
<a href="/wsjf-triage">Daily WSJF triage</a> is workplan-oriented advisory review.</p>`);
```
```js