Include decisions in pi hook output

[gregology]

Closes #124

PR #123 added decision support to the Claude adapter, but gated it behind plan mode since Claude Code has that concept. The pi adapter was left out entirely — HandlePiHook ignored result.DecisionEntries and only returned context.

This brings pi to parity. When core.Resolve returns matched decisions, they now show up in pi's additionalContext alongside any context entries.

Why always-on (no plan mode gating)?

The Claude adapter only surfaces decisions during permission_mode: "plan" to keep token costs low during normal tool use. Pi doesn't have an equivalent mode concept, so the two options were:

• Always include decisions — simple, and decisions are typically small. Users who don't define any won't see any difference.
• Never include decisions — safe but defeats the purpose. Pi users would have no way to get decisions surfaced.

Went with always-on. If pi adds a planning mode later, we can gate it then.

Review walkthrough

Single commit: Include decisions in pi hook output

• pi.go: Changed the early-return guard to check both ContextEntries and DecisionEntries. When decisions exist, appends formatDecisions() output (same helper the Claude adapter uses) to the response.
• pi_test.go: New TestHandlePiHook_Decisions with subtests covering decisions-only, both context and decisions (with full detail verification), and context-only (no spurious decisions section).
• README.md: Updated three spots where the docs described decisions as Claude-plan-mode-only. The pi integration section now mentions decisions too.

Developer metrics

Total duration: 6m 30s
Turns: 106
Tool calls: 77
Tokens: 1,429,407 input / 13,410 output

Stage	Model	Duration	Turns	Tool calls	Tokens (in/out)	Cache read	Cache creation
triage	claude-opus-4-6	1m 35s	36	31	86,252 / 1,534	60,758	25,487
decompose	claude-opus-4-6	0m 32s	7	6	167,223 / 1,118	136,876	30,336
implement_step_1	claude-opus-4-6	1m 53s	23	13	324,334 / 6,512	286,681	37,627
docs_review	claude-opus-4-6	1m 12s	21	12	410,068 / 2,473	369,542	40,506
craft_pr	claude-opus-4-6	1m 15s	19	15	441,530 / 1,773	385,664	55,850

Resolves #124

[gregology]

This could get noisy. Are there other signals we can use to determine if Pi is in planning mode?

[gregology]

Added an include_decisions field to PiHookInput so decisions are opt-in rather than always-on. This mirrors how Claude gates on permission_mode == "plan" — the Pi extension can set "include_decisions": true when it wants decisions surfaced.

Defaults to false, so existing integrations won't see any behavior change.

Re: whether Pi has a planning mode signal we could key off instead — that's outside what I can determine from the codebase. The current Pi extension protocol doesn't send anything mode-like, so this would need a design conversation about whether to extend the extension itself or if the opt-in flag is sufficient.

Developer metrics

Total duration: 3m 19s
Turns: 52
Tool calls: 42
Tokens: 418,661 input / 5,894 output

Stage	Model	Duration	Turns	Tool calls	Tokens (in/out)	Cache read	Cache creation
analyze_feedback	claude-opus-4-6	1m 32s	33	29	91,772 / 1,479	66,573	25,192
implement	claude-opus-4-6	1m 32s	18	12	254,551 / 4,182	215,638	38,889
craft_update	claude-opus-4-6	0m 14s	1	1	72,338 / 233	36,043	36,292

[gregology]

The Pi code base is on GitHub https://github.com/badlogic/pi-mono
Investigate to see if there is a signal we can use to determine when Pi is in planning mode or even a proxy for planning mode.

[gregology]

Added automatic planning-mode detection in the pi extension. When pi.getActiveTools() shows no mutating tools (edit, write), the extension now auto-sets include_decisions: true in the hook payload. So decisions surface during planning without users having to manually opt in.

It's a heuristic — depends on the plan-mode extension being installed — but the include_decisions field still works as a manual override on the Go side, so there's a fallback if the detection misfires.

Recorded the design decision (auto-detect + manual override) in the adapter's AGENTS.yaml with the alternatives we considered.

Out of scope: modifying pi's plan-mode extension itself to emit events on pi.events — that's a third-party extension we don't control. If pi ever adds native planning-mode events, we can drop the heuristic and listen for those directly.

Developer metrics

Total duration: 6m 16s
Turns: 99
Tool calls: 87
Tokens: 384,414 input / 5,074 output

Stage	Model	Duration	Turns	Tool calls	Tokens (in/out)	Cache read	Cache creation
analyze_feedback	claude-opus-4-6	3m 25s	39	36	67,178 / 1,333	52,276	14,898
implement	claude-opus-4-6	2m 28s	55	48	169,373 / 3,166	143,482	25,878
craft_update	claude-opus-4-6	0m 22s	5	3	147,863 / 575	115,326	32,532