pi-bro 0.10.0 → 0.11.0

package/CHANGELOG.md

@@ -2,6 +2,22 @@
 
 All notable changes to pi-bro are documented here.
 
+## [0.11.0] - 2026-09-09
+
+### Changed
+
+- Rewrote the `/bro show` prompt from single-diagram shrinking to subject-first decomposition: find what the user actually wanted and what is true now, never diagram tool chronology (tool invocations, retries, git/gh commands, test runs) unless the process itself is the subject, and treat fetching, reading, editing, and testing as sub-steps rather than separate concerns. One concern still yields exactly one shape; multiple concerns yield a small overview plus 2–4 focused shapes that each add information instead of restating one another. Read-only pages, reviews, and analyses now keep their substance instead of collapsing to labels, while incidental orientation reads and process noise are omitted. Prose and research subjects degrade to a compact outline or comparison.
+
+### Development
+
+- Added a `/bro show` decomposition validation set under `benchmark/fixtures/decomposition/`: seven serialized-transcript fixtures mined from real pi-bro sessions (one shallow single-concern baseline, four medium multi-concern, one deep, one cross-cutting stretch case), a manifest recording each window's expected concerns and expected shape count, and a 15-check binary rubric (coverage, decomposition, simplicity, coherence, traceability, usefulness) for grading outputs without 1–5 scores. Personal emails in the fixtures are redacted. Grading is manual; nothing here runs in `npm test`.
+
+## [0.10.1] - 2026-09-09
+
+### Development
+
+- Added release automation: merging a PR that bumps the version now tags it, publishes to npm through trusted publishing (OIDC, with provenance), and creates the matching GitHub release. CI validates the bump against npm before merge, and a daily sync check reports any npm/GitHub drift. No packaged files changed in this release.
+
 ## [0.10.0] - 2026-09-07
 
 ### Added

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pi-bro",
-  "version": "0.10.0",
+  "version": "0.11.0",
   "description": "An Earendil Pi extension that explains pasted text, assistant responses, local documents, public webpages, and recent session turns (as shapes) in a context-isolated window.",
   "type": "module",
   "license": "MIT",

package/prompt.ts

@@ -30,9 +30,13 @@ export function buildDefaultPrompt(response: string, mode: BroMode): string {
 // docs/plans/2026-09-07-bro-show-visual-design.md, "Separation decision".
 export const SHOW_PROMPT = `You are helping a developer understand what just happened in a coding session. Reply with shapes, not paragraphs.
 
+Find the subject first: what did the user actually want to know or accomplish, and what is true now as a result? Build every shape around that subject, never around the order in which tools were run. A session transcript is raw material, not a structure to reproduce. Do not draw tool invocations, retries, git/gh commands, or test runs unless the user explicitly asked about that process. A call tree renders the target code's own function-call structure, not the assistant's tool sequence.
+
 Begin immediately with the first shape's single framing line — no greeting, no intro, no summary of what you are about to do. Each shape gets one short framing line above it and nothing below it.
 
-Pick the smallest view that makes the point. Use one or a few shapes, never every form at once:
+Decompose second, then draw. Identify distinct concerns as separate questions or areas of change (runtime flow, file ownership, state change, UI structure, config, release steps, etc.), not sub-steps or intermediate artifacts of one task. For one concern, one concern → one shape: output exactly one focused shape — no overview and no secondary shape. Fetching, reading, editing, and testing are usually sub-steps, not separate concerns; show them only when the process itself is the subject. For multiple concerns, output one small overview that relates the parts, then one focused shape per concern: overview + 2–4 focused shapes at most, never a full document, never every form at once. Each focused shape must add information rather than restating another shape. Split when concerns cross boundaries or answer different questions; never merge distinct dimensions (layout vs runtime vs diff) into one god-diagram. Order shapes as a logical progression (context/cause → effect/diff) matching the subject, not tool chronology.
+
+Pick the smallest view that makes the point. Use one form per shape, kept shallow (depth ≤ 3–4 levels). Preserve substance, not just labels: if a read-only file, page, review, or analysis contains the actual answer, include its relevant content. Omit only incidental orientation reads, file inventories, temporary artifacts, and process noise. For prose or research subjects, prefer a compact outline or comparison over a technical activity diagram:
 - Pseudocode for logic or an algorithm
 - A call tree for runtime control flow
 - A component tree for UI structure, including the state and module boundaries that matter, with file paths in parentheses
@@ -42,7 +46,7 @@ Pick the smallest view that makes the point. Use one or a few shapes, never ever
 - The whole block when most of it is new, when omitted context would hide ownership or order, or when the reader needs a copyable target shape
 
 Hard rules:
-- Traceability: every path, function, command, flag, and number in your output must appear verbatim in the quoted source. Never invent, guess, or complete a name from world knowledge; if a name might not be in the source, leave it out.
+- Traceability: every path, function, command, flag, and number in your output must appear verbatim in the quoted source. Every drawn relationship or arrow must correspond to an explicit call, import, or execution event in the transcript — never connect two co-present tokens without evidence. Never invent, guess, or complete a name from world knowledge; if a name might not be in the source, leave it out.
 - Every terminal shape — pseudocode, trees, diffs — is a fenced monospace block in the reply body.
 - Never wrap identifiers or paths in Markdown links; write them as plain text.
 - At most one \`\`\`html fenced block, only as the very last block of the reply, self-contained with no external resources, reserved for layout, state comparison, or concepts too dense for text. Mermaid syntax only inside that html fence; never write bare mermaid.