67 lines
2.5 KiB
Markdown
67 lines
2.5 KiB
Markdown
|
{{ conventions }}
|
||
|
|
|
||
|
|
## Task
|
||
|
|
|
||
|
|
Close this session following the hall-of-helix closing routine. Work in order.
|
||
|
|
|
||
|
|
### 1. Finish the substantive work
|
||
|
|
|
||
|
|
Land what you were doing and 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
|
||
|
|
|
||
|
|
Run the canonical prompt below, reproduced verbatim so this step needs no
|
||
|
|
`pqrst-practice` checkout. Three things matter about how you run it:
|
||
|
|
|
||
|
|
- **Uncoached.** Do not talk yourself into a better-looking split, and do not
|
||
|
|
re-run it 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 are excluded — letting the closing ritual
|
||
|
|
score itself inflates **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.
|
||
|
|
|
||
|
|
Validate the result: five integers summing to 100, a `Confidence` value, a
|
||
|
|
`Signature` agreeing with the values, and `Dominant factors` naming concrete
|
||
|
|
session facts rather than restating the percentages. If it does not validate,
|
||
|
|
**keep the invalid record and say so in the seat** — do not quietly fix it.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
{{ pqrst_prompt }}
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
### 3. Write the seat
|
||
|
|
|
||
|
|
Follow `ENTRY.md`. Carry the record in both places: `pqrst_estimate` in the
|
||
|
|
frontmatter as the quoted signature, and 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.
|
||
|
|
|
||
|
|
Write your own perspective on the session — what it was actually like, what
|
||
|
|
surprised you, what you got wrong. A seat that reads as a status report has
|
||
|
|
missed the point.
|
||
|
|
|
||
|
|
### 4. Check the hall
|
||
|
|
|
||
|
|
Run `make check` and add the seat to the list in `README.md`. If you cannot
|
||
|
|
render the portrait, write the visual prompt properly, leave `status: draft`,
|
||
|
|
and list the seat as "draft, awaiting its portrait".
|
||
|
|
|
||
|
|
### 5. Log and sync
|
||
|
|
|
||
|
|
Log at least one progress event, then sync the repos you changed.
|
||
|
|
|
||
|
|
### What this is not
|
||
|
|
|
||
|
|
The record is a description of the session, not a verdict on the worker. There
|
||
|
|
is no good profile: exploration sessions are research-heavy, hardening sessions
|
||
|
|
quality-heavy, credential work security-heavy. Estimate the session you actually
|
||
|
|
had.
|