Ticket graphs

Every ticket as the root of its provenance graph — goal, patch, approval, runs and (as the ticket-class build lands) mandate, manifestations, guarantees, journey, artifacts and children. Rendered through the <<<TicketGraphList>>> tag.

← all ticket-graphs

DONE#155 congruency

Compile the playbook: audited lessons from settled tickets

goal

Write docs/PLAYBOOK.md: the playbook future workers read at birth. Distill the harvested lessons below into actionable guidance — what adversaries catch, how workers avoid it. Group by theme, keep each lesson checkable, cite the source ticket ids. Lessons: - [ticket #43] clean pass in 1 round — the adversary found nothing. Produced: Category-browse view: renders all categories (with page counts) and their annotation-tagged pages in one pass, plus single-category focus; reads the real annotations/Categories/Documents schema and SQL-verified against the live DB. - [ticket #46] clean pass in 1 round — the adversary found nothing. Produced: Bet/test tag harness: discovers every Tag_Interface tag under invocators/tags (mirrors TagList::scan), logs a `bet` prediction per tag to an append-only JSONL ledger (predict.py-modeled), boots an ephemeral php server (serve.py-modeled) to render each standalone as ?page=tags&tag=NAME, compares rendered-vs-predicted (clean-contract default or byte-exact --record-golden baseline), logs a PASS/FAIL `test` ticket, and provides a --view; verified end-to-end, 40/44 clean-pass with 4 real refutations. - [ticket #147] clean pass in 1 round — the adversary found nothing. Produced: Read-only version-discovery tool: reads git tags version-*, mirrors setup.py's _vkey/newest_version_tag so its numbers match what `setup.py install --version` accepts; default lists all installable versions (newest first, latest marked), --latest prints just the newest number, --json emits a {latest,count,versions} manifest. - [ticket #153] passed in 2 rounds. Rework forced by the adversary — round 1 findings: Requirement #2 violated (forbidden file creation): the state DB is in WAL journal mode, and the tool opens it with URI `mode=ro` only. Reading a WAL-mode DB that way creates `congruency.sqlite-shm` and `congruency.sqlite-wal` files in the state directory on every run — proven in isolation against a fresh copy (before: only `congruency.sqlite`; after running the tool with no other process touching it: `congruency.sqlite`, `-shm`, `-wal`). The ticket states it 'must never write to the db or create files' and the tool's own docstring claims it 'never creates a file'. Opening with `immutable=1` (or checkpointing) reads identical data and creates zero sidecar files, so the side effect is avoidable and attributable to the tool's connection choice. DB content hash is unchanged, but the 'never create files' guarantee is broken.. Resolution: READ-ONLY ticket rollup CLI (header/crew/journal/manifest/lessons/progress); opens the WAL-mode state db with immutable=1 so it creates no -wal/-shm sidecars (fixes the prior finding), '(none)' for missing pieces, exit 2 (no traceback) on missing id/db; verified against settled 151/152 and missing 999999. - [ticket #152] clean pass in 1 round — the adversary found nothing. Produced: Compiled the birth-time playbook from ticket #151's harvested lessons — grouped into four checkable themes (executable commands, internal consistency, live code-grounded citations, standalone clarity for the blind adversary), each tied to the adversary's finding rubric and cited to source ticket #151 and the current pair_loop.py/migrations. - [ticket #151] passed in 2 rounds. Rework forced by the adversary — round 1 findings: §6's first invocation example `python3 pair_loop.py --ticket 151` cannot be executed as written: pair_loop.py:178 declares `--deliverable` with required=True, so argparse rejects any invocation lacking it (`error: the following arguments are required: --deliverable`). Both documented forms need `--deliverable`, but the `--ticket` example omits it. | §4.2 is headed 'The routes, in the order an agent uses them' and lists `ticket.stops` 9th and `ticket.kind` 8th, contradicting the doc's own §5/§6: `ticket.stops` is the FIRST call (the BRAKE, pair_loop.py:208-213) and `ticket.kind` is set at ticket creation before `ticket.assign` (pair_loop.py:190). The stated order does not match the harness flow the same document describes.. Resolution: round 2: produced docs/TICKETS.md — Rewrote docs/TICKETS.md documenting the ticket-as-authorization surface (governance triggers, kinds/roles, lifecycle+steps_remaining, all routes, stop/start/graft edges, pair_loop.py iteration), grounded in 0029/0030/0001/0012/pair_loop.py, with §4.2 reordered to the true harness flow and §6 invocations corrected to include the required --deliverable.

patch

none

approval

unapproved

runs

no runs recorded

mandate (clauses)

not yet recorded — lands with the ticket-class build

manifestations

not yet recorded — lands with the ticket-class build

guarantees

not yet recorded — lands with the ticket-class build

journey (blunders & successes)

not yet recorded — lands with the ticket-class build

artifacts (forge)

not yet recorded — lands with the ticket-class build

source (forge tree)

browse congruency source (forge-parked tree)

children

not yet recorded — lands with the ticket-class build