audit: project incoming and outgoing task todo edges #51

New issue

Open

opened 2026-08-03 08:59:25 +00:00 by PerishFire · 0 comments

PerishFire commented

2026-08-03 08:59:25 +00:00

Owner

Observed

At Concord v0.9.2 and repository HEAD b11531a65e3118256baf6a959c484a2561a7ddbe, validated todo topology is absent from the documented task-entry audit.

For one current task:

$ concord task show --json perish.code/plumb-suite-adoption | jq '.task.todo'
[
  "plumb-release-radius",
  "substrate-verdict-snapshot"
]

$ concord task list --json \
  | jq -r '.[] | select((.task.todo // []) | index("plumb-suite-adoption")) | .identity'
perish.code/runseal-profile-cold-start

$ concord audit --json perish.code/plumb-suite-adoption \
  | jq '{faults, observations, has_todo: has("todo"), has_incoming: has("incoming")}'
{
  "faults": [],
  "observations": [],
  "has_todo": false,
  "has_incoming": false
}

task show serializes the task entry and therefore exposes only outgoing todos. Concord already computes incoming todos for rename, rehome, and finish, but Audit carries no topology records and task audit does not inspect todo links. An operator entering a task through memory read plus audit cannot see both sides of its dependency/handoff boundary without sweeping the registry.

This is not a dangling-registry defect: registry v3 rejects nonexistent todo targets, incoming links block target finish, and source finish emits explicit handoff actions.

Proposal

Add deterministic task-scoped todo topology to audit output, derived only from the validated same-domain registry:

emit sorted incoming and outgoing task identities for every audited task in human and JSON output;
keep them non-gating topology facts, not health verdicts or lifecycle state;
preserve the same projection for task, domain, and space audits.

Non-goals and existing-issue boundary

Do not add delivered/parked or target-acceptance state, scan opaque MAIN.md prose, require a todo target to have task memory, infer release-channel obligations, or turn todo into a scheduler/backlog.

This is separate from #11: a close macro composes existing finish checks but cannot expose retained tasks when no close operation is invoked. It is also narrower than #41's best-effort Git/member health observations: this proposal projects deterministic registry-owned topology rather than assessing work health.

## Observed At Concord `v0.9.2` and repository HEAD `b11531a65e3118256baf6a959c484a2561a7ddbe`, validated todo topology is absent from the documented task-entry audit. For one current task: ```console $ concord task show --json perish.code/plumb-suite-adoption | jq '.task.todo' [ "plumb-release-radius", "substrate-verdict-snapshot" ] $ concord task list --json \ | jq -r '.[] | select((.task.todo // []) | index("plumb-suite-adoption")) | .identity' perish.code/runseal-profile-cold-start $ concord audit --json perish.code/plumb-suite-adoption \ | jq '{faults, observations, has_todo: has("todo"), has_incoming: has("incoming")}' { "faults": [], "observations": [], "has_todo": false, "has_incoming": false } ``` `task show` serializes the task entry and therefore exposes only outgoing todos. Concord already computes incoming todos for rename, rehome, and finish, but `Audit` carries no topology records and task audit does not inspect todo links. An operator entering a task through `memory read` plus `audit` cannot see both sides of its dependency/handoff boundary without sweeping the registry. This is not a dangling-registry defect: registry v3 rejects nonexistent todo targets, incoming links block target finish, and source finish emits explicit handoff actions. ## Proposal Add deterministic task-scoped todo topology to audit output, derived only from the validated same-domain registry: - emit sorted incoming and outgoing task identities for every audited task in human and JSON output; - keep them non-gating topology facts, not health verdicts or lifecycle state; - preserve the same projection for task, domain, and space audits. ## Non-goals and existing-issue boundary Do not add delivered/parked or target-acceptance state, scan opaque `MAIN.md` prose, require a todo target to have task memory, infer release-channel obligations, or turn todo into a scheduler/backlog. This is separate from #11: a close macro composes existing finish checks but cannot expose retained tasks when no close operation is invoked. It is also narrower than #41's best-effort Git/member health observations: this proposal projects deterministic registry-owned topology rather than assessing work health.

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

PerishFire/concord#51

No description provided.

Rows
Columns