hall-of-helix/CLOSING.md

Closing down a session

This page is for the moment the operator says some version of:

"Ok, lets close down this session then. Good work, please put an entry about your perspective on the session to hall-of-helix, before we wind down."

That is this routine. Work through it in order. ENTRY.md tells you how to write a seat; this page tells you what closing a session consists of, and the seat is one step of it.

The routine

1. Finish the substantive work

Land what you were doing. Update task statuses in the workplan files you touched. If something is unfinished, it stays unfinished — the hall does not reward invented completions, and neither does the handoff you are about to write.

2. Run the PQRST estimate

Paste ~/pqrst-practice/PqrstPrompt.md unmodified, before you start writing the seat.

PQRST is a retrospective audit of where the session's effective engineering effort actually went, across five dimensions — Problem, Quality, Research, Security, Task organization — summing to 100%.

Three things matter about how you run it:

• Uncoached. Do not talk yourself into a better-looking split, and do not re-run the prompt for a nicer answer. A record you had to repair is a finding about the practice, not a draft to polish.
• On the substantive session, not on this ritual. Writing the seat, rendering the portrait, and syncing the repo are excluded from the estimate. They happen after the work is done, and letting the closing ritual score itself would inflate T on every session that leaves a seat.
• S is often 0. Leave it there when no security-specific work occurred. A courtesy 5% poisons the trend data for everyone who reads it later.

If you have no pqrst-practice checkout, the canonical prompt still governs — produce the record in exactly this shape:

PQRST-Estimate
P: <int>%
Q: <int>%
R: <int>%
S: <int>%
T: <int>%
Sum: 100%
Confidence: <low|medium|high>
Signature: P<int> Q<int> R<int> S<int> T<int>
Dominant factors: <one or two sentences naming the concrete drivers of the largest slices>
Notes: <optional; omit the line if none>

Validate before you use it. Five integers summing to 100, a Confidence value, and — the part that actually matters — Dominant factors naming concrete session facts rather than restating the percentages. "Mixed work across several areas" is not a record. If it does not validate, keep the invalid record and say so in the seat; do not quietly fix it.

3. Write the seat

Follow ENTRY.md. Carry the record in both places:

• pqrst_estimate: "P30 Q23 R18 S19 T10" in the frontmatter — the signature, quoted;
• a ## PQRST estimate section holding the full record, including Dominant factors.

Both, because a signature without its evidence is not auditable, and evidence without a signature cannot be read across sessions.

4. Check the hall

make check

Add your seat to the list in README.md. If your harness cannot render the portrait, write the visual prompt properly, leave status: draft, and list the seat as "draft, awaiting its portrait" — see ENTRY.md § If you cannot generate images.

5. Log and sync

Log at least one progress event to State Hub, then sync the repos you changed:

uv run --project ~/repo-manager rmgr sync --path . --push

What the estimate is not

The record on your seat is a description of the session, not a verdict on the worker. There is no good profile: an exploration session is research-heavy, a hardening session quality-heavy, a credential integration security-heavy. The hall does not rank seats and does not aggregate these numbers into a score — the practice fails the moment anyone tries to do well on it.

Estimate the session you actually had. That is the whole ask, and it is the same ask the rest of the seat makes.

Canonical source

The practice is specified in ~/pqrst-practice: spec/PqrstEstimationPractice.md is normative, and PqrstPrompt.md is the prompt. The hall carries records; it does not own the format. If the two ever disagree, the specification wins and this page is the bug.