the-custodian/workplans/CUST-WP-0060-work-record-canonization.md

id	type	title	domain	status	owner	topic_slug	planning_priority	planning_order	created	updated	state_hub_workstream_id
CUST-WP-0060	workplan	Work-record canonization — unified ontology, stages 1–2	infotech	finished	codex	custodian	high	60	2026-07-20	2026-07-20	68cb635b-8c6d-5e43-8def-0e520506bcf0

Work-record canonization — unified ontology, stages 1–2

Execute stages 1 (canonize) and 2 (schema + CI) of research/WorkOrchestrationArchitectureDraft.md v0.2 (founder-reviewed 2026-07-20): ratify the work-record umbrella ontology as canon and make it machine-enforced, with binky-control as pilot — its AWQ/DEC/OH queue items become schema-valid, hub-indexed work records without renaming a single id. Stages 3–6 (hub intake entity, generated views/index, tags & flow metrics, legacy retirement) follow in successor workplans once this foundation holds.

Origin: AWQ-010 sidetrack reintegration (2026-07-19); every artefact this plan lands exists to make that class of manual reintegration structurally unnecessary.

Task: Founder ratification of the two canon standards

Present work-record-types_v0.1.md (+ work-record-types.yaml) and autonomy-lanes_v0.1.md for founder review; apply edits; flip both from status: draft to status: active. Ratification is a decision work record (hub decision, red lane — canon change per constitution review gate). Yellow lane (preparation); resolution founder-only.

id: CUST-WP-0060-T01
status: done
priority: high
state_hub_task_id: "afacbb73-4285-5593-80ec-7ab4fe21375d"

Task: Extend workplan-terminology standard, don't fork it

Add the work-record umbrella and kind vocabulary to workplan-terminology-fleet_v0.1.md as a v0.2 revision (workplan and task definitions unchanged; new terms cross-referenced to work-record-types_v0.1.md). Update the terminology scan tooling exclusion list if needed. Green lane.

id: CUST-WP-0060-T02
status: done
priority: medium
state_hub_task_id: "2a5ee66b-c95c-5bdb-9784-e3d2eba781b6"

Task: YAML block schemas per kind

Author JSON-Schema definitions for the authored YAML block of each kind (intake, decision, engagement; task/workplan blocks already parsed by state-hub — align, don't duplicate). Schemas live in canon/standards/schemas/work-records/ with the machine registry as the pattern source. Include the spine-field requirements and grandfathered legacy patterns (AWQ-/DEC-/OH-). Green lane.

id: CUST-WP-0060-T03
status: done
priority: high
state_hub_task_id: "3bfabd1b-faf4-5f8f-93bb-b138912ebc97"

Task: Forgejo CI validation action

A reusable Forgejo workflow (repo-seed + rollout to control-plane repos) that validates all work-record YAML blocks in changed files against the schemas and the id-pattern registry on push/PR — the GitOps "validate before apply" gate and the first half of the sidetrack detector. Must be fast (<5 s), zero-config when the repo has no records. Blue lane.

id: CUST-WP-0060-T04
status: done
priority: high
state_hub_task_id: "50eded2b-62c0-55d6-b622-26251a80c250"

Task: fix-consistency sidetrack detector (C-25)

Extend statehub fix-consistency with a check that scans registered repos for id-like patterns ([A-Z]+-[A-Z]+-[0-9]+ heuristic) not matching the type registry and warns with the reintegration-cost message. No registration yet (that is stage 3) — detection only, so new species surface the day they appear. Green/Blue lane, lands in state-hub per its governance.

id: CUST-WP-0060-T05
status: done
priority: medium
state_hub_task_id: "03ff7177-9156-539f-a9c8-cb7266e958ed"

Task: binky-control pilot — queues schema-valid

Bring binky-control's live documents (AutopilotWorkQueue, DecisionQueue, OfficeHourQueue, RiskRegister) to schema validity: add missing spine fields (kind, lane, owner where absent) to open items, wire the CI action, run fix-consistency clean with the new checks. No id renames, no format migration — grandfathered patterns must pass as-is; that is the acceptance test for the grandfathering design. Blue lane (binky-control commits).

id: CUST-WP-0060-T06
status: done
priority: high
state_hub_task_id: "c05b4c51-2d78-5940-aaa9-afa6895e6ab7"

Task: Closure — stage-3 handoff package

Closure review per ADR-001; write the stage-3 successor workplan seed (state-hub intake entity, promotion transition CLI/MCP, generated per-repo index) with evidence from the pilot: schema friction observed, CI runtimes, detector findings across the fleet. Green lane.

id: CUST-WP-0060-T07
status: done
priority: medium
state_hub_task_id: "f0c6ab7e-47ef-5ef0-baf9-bfa02e09a65a"

Closure Review — 2026-07-20

Outcome: All 7 tasks completed same-day; stages 1–2 delivered end-to-end with green proof runs.

Completed

• T01 — canon ratified (founder, no edits; hub decision f4640f9e); both standards + machine registry flipped to active.
• T02 — workplan-terminology-fleet v0.2 addendum (umbrella vocabulary; file keeps _v0.1 name for reference stability).
• T03 — JSON schemas: canon/standards/schemas/work-records/ (spine/intake/decision/engagement; conditional spine requirements, historical grace for terminal records).
• T04 — tools/validate_work_records.py + reusable Forgejo workflow (repo-seed work-records.yaml). Substrate lesson: ubuntu-latest = node:20-bookworm, python via apt (first run failed 127, fixed).
• T05 — sidetrack detector landed as C-31 (C-25 was taken — the workplan text said C-25; registry numbering, not this plan, is authoritative). Unit-verified: rogue id flagged, grandfathered id passes.
• T06 — binky-control pilot green: 45 records, 0 errors, 0 warnings, zero id renames; CI run #1751 success. Registry additions during pilot: legacy task variants -T1, -LEGACY-Txx.
• T07 — this review.

Evidence

• Local runs: the-custodian 384 records / binky-control 45 records clean.
• CI: binky-control Work Records run 1747 (fail, substrate) → 1751 (green).
• fix-consistency on binky-control with C-31: 0 sidetrack warnings.

Stage-3 successor seed (next workplan, state-hub + the-custodian)

1. Intake entity in state-hub (fresh table per founder decision; UUIDv7 keys), fix-consistency registration for intake/decision/ engagement kinds (the write-back fields state_hub_intake_id etc. are already in the schemas).
2. Promotion transition as one CLI/MCP call (intake.routed → workplan|task|decision|engagement with promoted_to/origin back-links, both files written, both synced).
3. Generated per-repo work-record index (transclusion-style; markitect involvement) + regeneration of binky queue view tails as [auto].
4. Friction observations for stage 3: schema authoring cost was near zero for existing binky items (they passed unmodified); the only true churn risk is the view/authored split — keep authored blocks where they are, generate around them.
5. Suggestion-table close-out (read-only legacy) once the intake entity is live.
6. New report-sink for activity-core (added 2026-07-20, Forgejo-issue housekeeping session): daily-todo-md-stale-review was found still routing through the deployment-wide IssueSink (ISSUE_SINK_TYPE=rest → issue-core → Forgejo) — the only fleet consumer of the task_template rule action, and the source of 5 stale-review issues nobody was meant to see (Forgejo issue tracking is not the fleet coordination mechanism). Paused (enabled: false) rather than left running; re-enable requires a new activity-core report-sink type that authors a kind: intake work record in the target repo (per this workplan's stage-3 promotion design) instead of an IssueSink task spec. Any other ActivityDefinition that later adds a rule.action.task_template inherits the same trap — worth a fleet-wide grep before stage 3 ships.