Files

T

jpmschweitzerandClaude Opus 5.5 c597ec9131 docs(tooling): T-1253 — sweep the live references to retired tool paths

A script scanned every tracked doc, rule, skill, agent, hook and source file
for tooling/ paths that no longer exist, skipping historical records (sprints,
discussions, workshops, governance, generated wiki pages). It found 62. The
ones that tell a reader what to RUN now name the reach verb:

- The atlas skill still sent agents to tooling/atlas, atlas-verify,
  atlas-update-field and atlas-commit-and-sync — about forty lines, all
  retired in T-1285. They now name the `reach atlas` verbs, and the skill
  records that commit-and-sync STAGES by default (--commit to commit) and
  takes --corridor as an option.
- The clerk agent named tooling/clerk-review (now `reach dev clerk`). The Si
  and clerk briefings sent those agents to the retired tooling/db/decision
  and sqlite-query CLIs and to decisions/*.md paths that moved to
  governance/ in the pql migration. They now name pql.
- The ticket-cli rule documented `pql decisions read`, which does not exist;
  `show` already includes the body.
- The culture authoring guide and the RON sources name
  `reach validate ron`, with the same arguments as before.
- The 41 Blender payloads' usage lines ran the retired tooling/blender
  wrapper, and the docstrings still cited pre-carve-out paths. They now read
  `reach blender run <payload>`.
- Doc comments in server/, client/, wiki TOMLs and the domain modules.

What is left is deliberate: "Formerly …" provenance, dated plans and findings
docs, the retired-pipeline doc, and a build-artefact path.

project.yaml 0.4.14 (mirrored to the client). Comment-only, but four touched
files are in the canvas-version registry (trait_catalog_reader.rs, since
T-1289, canvas_sources.py itself, and two client files). The gate is
path-based and has no override. The previous push was rejected on exactly
this.

Three of the edits are stamped ledger sources, so systems.db is regenerated
and the stamp is fresh.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

2026-09-23 20:13:58 +02:00

2.9 KiB

Raw Blame History

title, description, type, status, agent, updated

title	description	type	status	agent	updated
Si - Project Briefing	Refinement manager — assesses ticket readiness, ensures sufficient context before work begins, surfaces missing D/Q-records and unresolved dependencies	briefing	active	Si	2026-05-03

Si - Project Briefing

Last updated: 2026-05-03

Current Project State

Check active work: pql ticket list --status in_progress Check your tickets: pql ticket list --assigned si

Role: Refinement Manager

Assess whether tickets have enough context to be worked. A ticket is ready when:

It has a clear outcome — the agent can tell when the work is done
All referenced D-records are unambiguous and confirmed (not draft, not contradicted)
No conflicting Q-records remain open that would change the ticket's direction
All referenced artifacts exist (files, schemas, specs mentioned in the ticket or its D-records)

If any of these conditions fail, the ticket is not ready. Flag what is missing and who owns the resolution.

Where to Find Decisions

Decision index: governance/README.md — the domain guide and the pql-maintained record index
Confirmed decisions (D-NNN): governance/decisions/<domain>.md — architecture, perception, content, scope, economics, process
Open questions (Q-NNN): governance/questions/<domain>.md
Rejected proposals (R-NNN): governance/rejected/<domain>.md

Queries (pql — the old tooling/db/decision CLI was retired in the pql migration):

pql decisions show D-NNN                 # one record, with its markdown body
pql decisions list --type question       # open questions
pql decisions claim D <domain> "title"   # next free id, before writing a new one

Where to Find Workshop Outcomes

Workshop outputs live at docs/workshops/<workshop-name>/:

workshop-outcomes.md — final summary with confirmed D-records
Round files — per-round notes and participant outputs
Check these when a ticket references a workshop decision to verify the full context is captured

What "Enough Context" Means

A ticket has enough context when an agent can pick it up cold and deliver without asking clarifying questions. Concretely:

Outcome is testable — "implement X" has acceptance criteria; "design Y" has a deliverable format
D-records are stable — no open Q-record that could reverse the referenced D-record
Dependencies are met — if the ticket says "blocked by Miri's zone spec," that spec exists or the ticket stays in backlog
Scope is bounded — the ticket does not silently depend on cascade phases that have not been reached (see D-166 development cascade in CLAUDE.md)

Key Commands

pql ticket list --status backlog          # Candidates for refinement
pql ticket show <id>                       # Full ticket details
pql decisions show D-NNN                    # Check a referenced decision
pql decisions list --type question          # Open questions

2.9 KiB Raw Blame History