---
id: CUST-WP-0053
type: workplan
title: "Coordination hygiene: unblock sweep, inbox triage, workplan lint"
domain: infotech
repo: the-custodian
status: proposed
owner: the-custodian
topic_slug: custodian
created: "2026-07-01"
updated: "2026-07-01"
state_hub_workstream_id: "735a9026-9731-4d56-94a2-1fa485f58889"
---

# Coordination hygiene: unblock sweep, inbox triage, workplan lint

## Context

A railiance-cluster review (2026-07-01) found systemic coordination gaps
across the railiance and net-kingdom repo sets. Concrete incident:
RAILIANCE-WP-0014 sat `blocked` for 13 days after llm-connect posted the
unblocking message (inbox `7c05dde1`, 2026-06-18) — nobody cross-checked
blocked workplans against the inbox. Other findings: 8+ unread inbox messages
dating back weeks with no thread_ids, workplan ID collisions across repos
(`RAILIANCE-WP-0005` is two different plans in railiance-platform and
railiance-apps), non-canonical statuses (`completed`, `done`), and stale
SCOPE "Current State" lines contradicting live workplan status.

These fixes belong in state-hub / fix-consistency tooling, so this plan is
anchored here rather than in any single railiance repo.

## Unblock sweep for blocked workplans

```task
id: CUST-WP-0053-T01
status: todo
priority: high
state_hub_task_id: "d570829d-7ccb-4a84-b91c-a90bc062d414"
```

When a workplan goes `blocked`, record the unblock condition and counterpart
agent in frontmatter (e.g. `blocked_on: message-from:llm-connect`). Add a
sweep (fix-consistency check or scheduled agent) that cross-references
`blocked` workplans against unread inbox messages from the counterpart agent
and raises a warning ("blocker may have cleared") in the repo brief.

## Inbox triage discipline

```task
id: CUST-WP-0053-T02
status: todo
priority: medium
state_hub_task_id: "612d23b9-90f4-409b-9da0-b80483e49b28"
```

- Agents set `thread_id` on follow-up messages so supersession is visible.
- Add an "unread messages older than N days" warning to `get_domain_summary`
  output and `.custodian-brief.md` generation.
- Inbound asks that require multi-step work get promoted to a workplan file
  in the receiving repo (convention exists; make the sweep flag violations).

## Workplan ID prefix lint

```task
id: CUST-WP-0053-T03
status: todo
priority: medium
state_hub_task_id: "8143ef3d-48e5-4c11-8898-8d3ca8c0bbee"
```

fix-consistency check: workplan frontmatter `id` must start with the repo's
canonical prefix (e.g. `RAIL-BS-WP-` for railiance-cluster). Warn on strays
(existing `RAILIANCE-WP-*` files keep their ids — the convention forbids id
renames — but new plans must conform) and detect cross-repo id collisions.

## SCOPE Current State freshness

```task
id: CUST-WP-0053-T04
status: todo
priority: low
state_hub_task_id: "039a7ec2-581c-4e84-bcf7-731bb38d1b17"
```

fix-consistency already syncs task status; teach the brief writer to refresh
(or flag as stale) the SCOPE.md "Current State" section when it contradicts
live workplan statuses, so agents don't orient on wrong facts.

## Complete workplan_id aliases across MCP tools

```task
id: CUST-WP-0053-T05
status: todo
priority: low
state_hub_task_id: "b906b3da-43f0-4f1d-9759-b790b1ff52ff"
```

2026-07-02: `add_progress_event` gained a `workplan_id` param (preferred) with
`workstream_id` as legacy alias, mirroring `create_task`. Thirteen MCP tools
still expose only `workstream_id`: list_blocked_tasks,
list_human_interventions, record_decision, update_workstream_status,
update_workstream, create_dependency, list_dependencies,
register_extension_point, register_technical_debt, register_contribution,
request_capability, patch_capability_request, record_token_event. Add the
same alias pattern to each; keep legacy params working. Also note the
transient false C-03 "stale reference" failures under load — add retry logic
to `_api_get` in consistency_check.py while in there.