pqrst-practice/workplans/PQRST-WP-0002-validate-v01-against-real-sessions.md

id	type	title	domain	repo	status	owner	topic_slug	priority	created	updated	quality_dor	quality_dor_at	quality_dor_by	quality_dor_note	related
PQRST-WP-0002	workplan	Validate spec v0.1 against real sessions and cut v0.2	agents	pqrst-practice	proposed	claude-code	practice	high	2026-09-05	2026-09-05	DoR-Ok	2026-09-05	claude-code	v0.1 consolidates two drafts that were written without either being applied to a session. Every open question is empirical — whether the prompt returns a valid record unassisted, whether attribution by primary purpose is decidable in practice, and where records are stored — so the next change is a bounded pilot, not more specification.	PQRST-WP-0001

Validate spec v0.1 against real sessions and cut v0.2

Spec v0.1 was consolidated from two independent drafts, neither of which had been applied to an actual session. It is internally consistent and entirely unvalidated.

The purpose of this workplan is to find out where the practice is wrong by using it, then cut v0.2 from the findings. It deliberately does not build tooling or a record store — both are out of scope for this repository (SCOPE.md).

Done when: the prompt has been run unassisted at the end of at least eight real sessions, the friction is written down, the storage boundary is decided, and v0.2 either incorporates the findings or records why v0.1 stands.

Pilot the closing prompt on real sessions

id: PQRST-WP-0002-T01
status: todo
priority: high

Paste PqrstPrompt.md unmodified at the end of at least eight real agentic coding sessions, spread across at least three repositories and at least two task classes (e.g. feature, bugfix, explore, harden).

Do not coach the model, do not repair a malformed answer, and do not re-run the prompt for a better result. A rejected record is the finding.

For each session capture, in this file under "Pilot findings":

• the returned record verbatim;
• whether it passed spec §5.5 validation on the first attempt;
• whether Dominant factors cited concrete session facts or restated the percentages;
• any dimension the model hedged on, refused, or visibly guessed at;
• the task class and the repository.

The specific questions to answer:

1. Does an uncoached agent return a valid record from the prompt alone?
2. Is "attribute by primary purpose" (spec R5) actually decidable mid-estimate, or does it collapse under overlap?
3. Does S stay at 0 when security work did not occur, or does it drift upward?
4. Do estimates cluster at coarse increments (R7), or does false precision reappear?
5. Is Confidence used meaningfully, or is it always medium?

Decide the record-storage boundary

id: PQRST-WP-0002-T02
status: todo
priority: high

SCOPE.md excludes record storage from this repository but does not say where records go instead. Until that is answered the practice produces records with nowhere to live, and the trend analysis that justifies the whole exercise (spec §8, §9) cannot happen.

Decide and record the answer as a decision (POST /decisions/, then an ADR in this repo if the decision has repo-local consequences). Options to weigh:

• a State Hub surface (progress events already carry free text; a dedicated record type would need a hub change and is a bigger commitment);
• an append-only file in each consuming repository;
• a separate collection repository outside this one.

Whatever is chosen, this repository still ships no collector — the decision names the owner, it does not move the work here.

Cut spec v0.2

id: PQRST-WP-0002-T03
status: todo
priority: medium

From the pilot findings, revise the specification and prompt together:

• fix rules the pilot showed to be undecidable or routinely ignored;
• tighten or relax the validation rules based on what actually failed;
• add the storage-boundary decision from T02 as a SCOPE.md cross-reference;
• bump to v0.2 and add a row to the spec's Appendix B.

If a change alters a dimension's meaning, the validation rules, or the stored record format, say plainly in Appendix B that records made under v0.1 are less comparable.

If the pilot surfaces nothing substantive, record that outcome and leave v0.1 standing. "No change needed, and here is the evidence" is a valid result and a better one than churn.

Run the verification checklist in AGENTS.md before committing, then sync:

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

Pilot findings

Populated by T01. One subsection per session: repository, task class, the verbatim record, and whether it validated unassisted.