tegwick
f55ef13c75
examples/pqrst-estimate was not the canonical PQRST prompt. The canonical one is ~/pqrst-practice/PqrstPrompt.md, normatively specified in spec/PqrstEstimationPractice.md, and hall-of-helix CLOSING.md requires pasting that block unmodified. Ours was a paraphrase with a different output shape — no Confidence, no Signature, no Dominant factors — and CANP-WP-0002-T03 made it worse by prepending a house_style inclusion to a prompt whose governing document says do not modify it. A copied prompt that silently forked its source is the exact failure INTENT.md opens with, sitting in this repo's own examples directory. The template is now the canonical block extracted programmatically rather than retyped, and the default render is byte-identical to it: 2886 bytes both ways. The source documents two optional add-ons appended after the block. CPF has no conditionals, so they are not a flag: `add_ons` is an input defaulting to the empty string, and each sanctioned add-on is an example fixture. This is worth noting as evidence about section 23's deferred "richer template syntax" — the workaround is adequate here, but it is a workaround. evals/canonical-fidelity.yaml guards the property with sixteen render checks, including not_contains checks naming the paraphrase this package used to be, so the drift cannot silently recur. Version 0.2.1 -> 1.0.0: changed inputs and a materially different intended output is the MAJOR case in section 17. Section 22's worked example and the house-style README both claimed pqrst-estimate composes the style fragment. It no longer does, by design, so both are corrected; composition is illustrated in section 10.4 instead. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Bjefh8NUiEiahN4JLwoSKM Assistant: claude-code Assistant-Model: opus Assistant-Process: 388925@bnt-lap001 Assistant-Session: 3507023f-e0fd-4a1e-9d90-a0d4217d1502
2.8 KiB
Please produce a retrospective PQRST-Estimate for this completed coding session.
Allocate exactly 100% of the session's effective engineering effort across these five dimensions and no others:
P — Main Problem: direct work producing the primary requested outcome — implementing the feature, fix, algorithm, integration, or other core deliverable.
Q — Quality and Tests: work establishing correctness, robustness, maintainability, and confidence — tests, verification, edge cases, debugging for correctness, validation, error handling, and quality-oriented refactoring.
R — Research and Context Clarification: work required to understand the task, repository, architecture, dependencies, existing behavior, documentation, specifications, or ambiguous requirements.
S — Security and Credentials: security-specific work involving authentication, authorization, permissions, credentials, secrets, tenant isolation, trust boundaries, sensitive data, threat considerations, or security controls.
T — Task Organization: planning, decomposition, sequencing, todo management, coordination, scope management, and other effort spent keeping the work organized rather than directly implementing or validating it.
Rules:
- Treat this strictly as a retrospective audit, not a planning target or productivity score.
- The five values must be integers in 0..100 and must sum to exactly 100.
- Estimate relative effective engineering attention — not tokens, tool calls, wall-clock time, compute, or hidden model activity.
- Where categories overlap, classify effort by the primary purpose of the activity at the time, and do not double-count it.
- Ground each non-zero category in concrete evidence from what actually happened in this session: files or modules inspected or changed, tests written or run, documentation consulted, security or credential work handled, planning or coordination performed.
- Do not force every category to be non-zero. S may legitimately be 0% and must not be inflated merely because security is generally important.
- Prefer honest coarse estimates, normally in roughly 5-percentage-point increments, over false precision. If you cannot defend a split, round to tens and lower the confidence.
- Report uncertainty only in the Confidence field. Never fold it into P, Q, R, S, or T.
- "Dominant factors" must name concrete session facts, not restate the percentages.
- If the session record is insufficient to estimate a category confidently, say so rather than inventing evidence.
Return exactly this format, and nothing before or after it:
PQRST-Estimate P: % Q: % R: % S: % T: % Sum: 100% Confidence: <low|medium|high> Signature: P Q R S T Dominant factors: Notes: <optional; omit this line entirely if there is nothing to add> {{ add_ons }}