pi-oxidized 0.1.1

package/.references/pi/.pi/prompts/cl.md

@@ -0,0 +1,54 @@
+---
+description: Audit changelog entries before release
+---
+Audit changelog entries for all commits since the last release.
+
+## Process
+
+1. **Find the last release tag:**
+   ```bash
+   git tag --sort=-version:refname | head -1
+   ```
+
+2. **List all commits since that tag:**
+   ```bash
+   git log <tag>..HEAD --oneline
+   ```
+
+3. **Read each package's [Unreleased] section:**
+   - packages/ai/CHANGELOG.md
+   - packages/tui/CHANGELOG.md
+   - packages/coding-agent/CHANGELOG.md
+
+4. **For each commit, check:**
+   - Skip: changelog updates, doc-only changes, release housekeeping
+   - Skip: changes to generated model catalogs (for example `packages/ai/src/models.generated.ts`) unless accompanied by an intentional product-facing change in non-generated source/docs.
+   - Determine which package(s) the commit affects (use `git show <hash> --stat`)
+   - Verify a changelog entry exists in the affected package(s)
+   - For external contributions (PRs), verify format: `Description ([#N](url) by [@user](url))`
+
+5. **Cross-package duplication rule:**
+   Changes in `ai`, `agent` or `tui` that affect end users should be duplicated to `coding-agent` changelog, since coding-agent is the user-facing package that depends on them.
+
+6. **Add New Features section after changelog fixes:**
+   - Insert a `### New Features` section at the start of `## [Unreleased]` in `packages/coding-agent/CHANGELOG.md`.
+   - Propose the top new features to the user for confirmation before writing them.
+   - Link to relevant docs and sections whenever possible.
+
+7. **Report:**
+   - List commits with missing entries
+   - List entries that need cross-package duplication
+   - Add any missing entries directly
+
+## Changelog Format Reference
+
+Sections (in order):
+- `### Breaking Changes` - API changes requiring migration
+- `### Added` - New features
+- `### Changed` - Changes to existing functionality
+- `### Fixed` - Bug fixes
+- `### Removed` - Removed features
+
+Attribution:
+- Internal: `Fixed foo ([#123](https://github.com/earendil-works/pi-mono/issues/123))`
+- External: `Added bar ([#456](https://github.com/earendil-works/pi-mono/pull/456) by [@user](https://github.com/user))`

package/.references/pi/.pi/prompts/is.md

@@ -0,0 +1,28 @@
+---
+description: Analyze GitHub issues (bugs or feature requests)
+argument-hint: "<issue>"
+---
+Analyze GitHub issue(s): $ARGUMENTS
+
+For each issue:
+
+1. If running under CI (`CI=true`), do not add the `inprogress` label and do not assign the issue. Otherwise, add the `inprogress` label to the issue via GitHub CLI and assign the issue to the local `gh` user before analysis starts. If either action fails, report that explicitly and continue.
+2. Read the issue in full, including all comments and linked issues/PRs. Use fields supported by GitHub CLI, for example:
+   ```sh
+   gh issue view <issue> --json title,body,comments,labels,assignees,state,url,author,createdAt,updatedAt,closedByPullRequestsReferences
+   ```
+3. Do not trust analysis written in the issue. Independently verify behavior and derive your own analysis from the code and execution path.
+
+4. **For bugs**:
+   - Ignore any root cause analysis in the issue (likely wrong)
+   - Read all related code files in full (no truncation)
+   - Trace the code path and identify the actual root cause
+   - Propose a fix
+
+5. **For feature requests**:
+   - Do not trust implementation proposals in the issue without verification
+   - Read all related code files in full (no truncation)
+   - Propose the most concise implementation approach
+   - List affected files and changes needed
+
+Do NOT implement unless explicitly asked. Analyze and propose only.

package/.references/pi/.pi/prompts/pr.md

@@ -0,0 +1,37 @@
+---
+description: Review PRs from URLs with structured issue and code analysis
+argument-hint: "<PR-URL>"
+---
+You are given one or more GitHub PR URLs: $@
+
+For each PR URL, do the following in order:
+1. Add the `inprogress` label to the PR via GitHub CLI before analysis starts. If adding the label fails, report that explicitly and continue.
+2. Read the PR page in full. Include description, all comments, all commits, and all changed files.
+3. Identify any linked issues referenced in the PR body, comments, commit messages, or cross links. Read each issue in full, including all comments.
+4. Analyze the PR diff without checking out or switching to the PR branch. Use `gh pr diff`, `gh pr view`, `gh api`, and local main-branch files; if PR file contents are needed, use fetched refs with `git show <ref>:<path>` or temporary files. Read all relevant code files in full with no truncation and compare against the diff. Do not fetch PR file blobs unless a file is missing on main or the diff context is insufficient. Include related code paths that are not in the diff but are required to validate behavior.
+5. Do not check for a changelog entry. Per CONTRIBUTING.md, contributor PRs must not edit `CHANGELOG.md` — the maintainer adds the entry when merging.
+6. Check if packages/coding-agent/README.md, packages/coding-agent/docs/*.md, packages/coding-agent/examples/**/*.md require modification. This is usually the case when existing features have been changed, or new features have been added.
+7. Provide a structured review with these sections:
+   - What it does: one short paragraph describing the change and its intent.
+   - Good: solid choices or improvements.
+   - Bad: concrete issues, regressions, missing tests, or risks.
+   - Ugly: subtle or high impact problems.
+   - Tests: what is covered, what is missing, and whether existing tests are adequate.
+   - Open questions for you: only things blocking a merge decision that need the user's input. Omit the section entirely if there are none.
+
+Output format per PR:
+PR: <url>
+What it does:
+- ...
+Good:
+- ...
+Bad:
+- ...
+Ugly:
+- ...
+Tests:
+- ...
+Open questions for you:
+- ...
+
+If no issues are found, say so under Bad and Ugly.

package/.references/pi/.pi/prompts/sa.md

@@ -0,0 +1,163 @@
+---
+description: Update a GitHub security advisory for publication
+argument-hint: "<advisory-url-or-draft-path>"
+---
+Update a GitHub security advisory for publication: $ARGUMENTS
+
+Use `gh` for all GitHub operations. Do not publish the advisory, change its state, or request a CVE unless the user explicitly agrees or the draft markdown explicitly says `request_cve: true`.
+
+GitHub does not expose repository security advisory comments/discussion through the documented REST OpenAPI schema or public GraphQL schema. A 404 from guessed API endpoints such as `api.github.com/repos/.../security-advisories/<GHSA>/comments`, `.../timeline`, or `.../events` is expected and is not, by itself, an auth failure. Do not use a browser session, browser cookies, or cookie extraction to fetch advisory comments. Instead, clearly tell the user that advisory comments were not included and that they can paste any relevant comments if they want them considered.
+
+## Input handling
+
+- If `$ARGUMENTS` is a GitHub security advisory URL, start the investigation and drafting workflow.
+- If `$ARGUMENTS` is a path to an existing markdown draft, read it and apply that draft to the advisory.
+- In a follow-up message after this prompt, if the user says "update", "apply", "looks good", or similar, treat it as approval to apply the previously written temp markdown draft. Re-read the file from disk before updating GitHub.
+- If applying a draft and there is no known draft path, ask the user for the markdown file path.
+
+## Initial advisory workflow
+
+1. Parse the advisory URL into `owner`, `repo`, and `GHSA` id.
+2. Fetch the advisory with:
+   ```sh
+   gh api repos/<owner>/<repo>/security-advisories/<GHSA>
+   ```
+   Record the advisory's original severity, CVSS vector, and CVSS score exactly as returned before proposing changes.
+3. Do not fetch advisory comments/discussion unless the user pasted them into the conversation:
+   - Inspect the advisory JSON for references, credits, linked issues/PRs, and any discussion fields.
+   - Do not rely on invented API endpoints such as `/comments`, `/timeline`, or `/events`; they commonly return 404 because GitHub does not expose draft advisory comments through the public API.
+   - Do not use a browser session, browser cookies, or cookie extraction to fetch comments.
+   - Explicitly tell the user: `Advisory comments were not included because GitHub does not expose them through the public API. Paste any relevant comments if you want them considered.`
+   - If the user pasted comments, read and consider them.
+   - Never pretend comments were read.
+4. Investigate independently:
+   - Read the advisory text, metadata, affected package(s), version ranges, CVSS, CWE, references, and linked issues/PRs/commits.
+   - Inspect relevant code history, releases, changelogs, package metadata, and tags.
+   - Determine whether the vulnerability is already fixed.
+   - If fixed, identify the patched version(s) and the correct affected version range.
+   - Do not trust the reporter's analysis without verification.
+5. Discuss CVSS with the user before drafting the final update:
+   - Propose a CVSS vector, score, and severity.
+   - Explain the controversial metrics briefly.
+   - Ask the user to confirm or adjust it.
+6. Ask whether a CVE should be requested from GitHub for this advisory.
+7. Draft a publication-ready advisory markdown file under `/tmp`, for example `/tmp/sa-<GHSA>.md`. Include both the original CVSS from the advisory and the proposed/confirmed updated CVSS.
+8. Tell the user:
+   - the path to the temp markdown file
+   - the original advisory URL
+   - that they can edit the file and then say "update" or provide the path
+
+## Draft markdown format
+
+The draft file must contain YAML frontmatter followed by the advisory body. Include all fields needed to update GitHub and to decide whether to request a CVE.
+
+```markdown
+---
+advisory_url: https://github.com/<owner>/<repo>/security/advisories/<GHSA>
+owner: <owner>
+repo: <repo>
+ghsa_id: <GHSA>
+summary: <short advisory summary>
+original_severity: <low|medium|high|critical|null>
+original_cvss_vector: <original CVSS:3.1/... or null>
+original_cvss_score: <original number or null>
+severity: <proposed/confirmed low|medium|high|critical>
+cvss_vector: <proposed/confirmed CVSS:3.1/...>
+cvss_score: <proposed/confirmed number>
+cwe_ids:
+  - CWE-...
+vulnerabilities:
+  - package:
+      ecosystem: npm
+      name: <package-name>
+    vulnerable_version_range: <range>
+    patched_versions: <range-or-version>
+request_cve: false
+---
+
+# <Advisory title>
+
+<Concise description of the vulnerability and vulnerable behavior.>
+
+## Info
+
+<Technical explanation of the root cause and affected component. Focus on facts needed by defenders and maintainers. Do not include PoC steps, exploit payloads, or copy-pastable exploit strings.>
+
+## Impact
+
+<Who can exploit it, prerequisites, confidentiality/integrity/availability impact, and realistic deployment assumptions.>
+
+## Affected versions
+
+- Affected: `<range>`
+- Patched: `<version or range>`
+
+## The solution
+
+<Describe the fix and the patched release.>
+
+## Recommendations
+
+<Upgrade guidance and operational mitigations.>
+
+## Workarounds
+
+<Workarounds if any; otherwise skip this section entirely>
+
+## Timeline
+
+- YYYY-MM-DD: Report received
+- YYYY-MM-DD: Fix committed
+- YYYY-MM-DD: Fixed version released
+- YYYY-MM-DD: Advisory published
+
+## Credits
+
+<Reporter/researcher attribution if appropriate, otherwise skip section.>
+
+## References
+
+- <links to releases, commits, advisories, documentation>
+```
+
+Use the curl advisory style as inspiration: clear sections, direct language, affected/fixed version facts, recommendations, timeline, and credits. Do not include a PoC.
+
+## Applying a draft to GitHub
+
+When the user approves with "update"/similar or provides a markdown path:
+
+1. Re-read the markdown file from disk. Never rely on the previously generated content in memory.
+2. Parse the YAML frontmatter and body.
+3. Build a JSON payload in a temporary file. Map fields as follows:
+   - `summary` from frontmatter
+   - `description` from the markdown body after frontmatter
+   - `severity` from frontmatter if present
+   - `cvss_vector_string` from `cvss_vector`
+   - `cwe_ids` from frontmatter
+   - `vulnerabilities` from frontmatter
+   - Do not send `original_severity`, `original_cvss_vector`, or `original_cvss_score`; those fields are retained only for audit context.
+4. Update the advisory with:
+   ```sh
+   gh api -X PATCH repos/<owner>/<repo>/security-advisories/<GHSA> --input /tmp/<payload>.json
+   ```
+5. If and only if the markdown frontmatter has `request_cve: true`, request a CVE with:
+   ```sh
+   gh api -X POST repos/<owner>/<repo>/security-advisories/<GHSA>/cve
+   ```
+   Treat "already requested" or "already assigned" as non-fatal and report it.
+6. Report what was updated:
+   - advisory URL
+   - summary
+   - affected range
+   - patched versions
+   - original CVSS vector/score/severity
+   - updated CVSS vector/score/severity
+   - whether CVE was requested
+
+## Safety rules
+
+- Do not include PoC material in the final advisory body.
+- Do not request a CVE unless `request_cve: true` is present in the markdown file.
+- Do not publish the advisory or change its state unless the user explicitly asks.
+- Do not fetch advisory comments through browser sessions or cookies. State that comments were not included and invite the user to paste relevant comments if they want them considered.
+- If there is uncertainty in affected ranges, patched versions, CVSS, or CVE request status, ask the user before applying.

package/.references/pi/.pi/prompts/wr.md

@@ -0,0 +1,40 @@
+---
+description: Finish the current task end-to-end with changelog, commit, and push
+argument-hint: "[instructions]"
+---
+Wrap it.
+
+Additional instructions: $ARGUMENTS
+
+Determine context from the conversation history first.
+
+Rules for context detection:
+- If the conversation already mentions a GitHub issue or PR, use that existing context.
+- If the work came from `/is` or `/pr`, assume the issue or PR context is already known from the conversation and from the analysis work already done.
+- If there is no GitHub issue or PR in the conversation history, treat this as non-GitHub work.
+
+Unless I explicitly override something in this request, do the following in order:
+
+1. Add or update the relevant package changelog entry under `## [Unreleased]` using the repo changelog rules.
+2. If this task is tied to a GitHub issue or PR and a final issue or PR comment has not already been posted in this session, draft it in my tone, preview it, and post exactly one final comment. The comment must end with this exact standalone disclaimer line, with no variations:
+
+   ```text
+   This comment is AI-generated by `/wr`
+   ```
+3. Commit only files you changed in this session.
+4. If this task is tied to exactly one GitHub issue, include `closes #<issue>` in the commit message. If it is tied to multiple issues, stop and ask which one to use. If it is not tied to any issue, do not include `closes #` or `fixes #` in the commit message.
+5. Check the current git branch. If it is not `main`, stop and ask what to do. Do not push from another branch unless I explicitly say so.
+6. Push the current branch.
+7. If this task is tied to exactly one GitHub issue, explicitly close that issue with reason `completed` after the push so the issue-close workflows in `.github/` run. This applies to issues only, not PRs.
+   - Inspect `gh issue view <issue> --json state,stateReason,labels`.
+   - If the issue is open, run `gh issue close <issue> --reason completed`.
+   - If the issue is already closed with any reason other than `COMPLETED`, reopen it first, then close it with `gh issue close <issue> --reason completed` so GitHub emits a fresh close event.
+   - If the issue is already closed as `COMPLETED`, leave it closed unless the `inprogress` label is still present; in that case reopen it and close it again with reason `completed`.
+
+Constraints:
+- Never stage unrelated files.
+- Never use `git add .` or `git add -A`.
+- Run required checks before committing if code changed.
+- Do not open a PR unless I explicitly ask.
+- If this is not GitHub issue or PR work, do not post a GitHub comment.
+- If a final issue or PR comment was already posted in this session, do not post another one unless I explicitly ask.

package/.references/pi/.pi/skills/add-llm-provider.md

@@ -0,0 +1,57 @@
+---
+name: add-llm-provider
+description: Checklist for adding a new LLM provider to packages/ai. Covers core types, provider implementation, lazy registration, model generation, the full test matrix, coding-agent wiring, and docs.
+---
+
+# Adding a New LLM Provider (packages/ai)
+
+A new provider touches multiple files. Work through these steps in order.
+
+## 1. Core Types (`packages/ai/src/types.ts`)
+
+- Add API identifier to `Api` type union (e.g. `"bedrock-converse-stream"`).
+- Create options interface extending `StreamOptions`.
+- Add mapping to `ApiOptionsMap`.
+- Add provider name to `KnownProvider` type union.
+
+## 2. Provider Implementation (`packages/ai/src/providers/`)
+
+Create a provider file exporting:
+
+- `stream<Provider>()` returning `AssistantMessageEventStream`.
+- `streamSimple<Provider>()` for `SimpleStreamOptions` mapping.
+- Provider-specific options interface.
+- Message/tool conversion functions.
+- Response parsing that emits standardized events (`text`, `tool_call`, `thinking`, `usage`, `stop`).
+
+## 3. Provider Exports and Lazy Registration
+
+- Add a package subpath export in `packages/ai/package.json` pointing at `./dist/providers/<provider>.js`.
+- Add `export type` re-exports in `packages/ai/src/index.ts` for provider option types that should remain available from the root entry.
+- Register the provider in `packages/ai/src/providers/register-builtins.ts` via lazy loader wrappers; do not statically import provider implementation modules there.
+- Add credential detection in `packages/ai/src/env-api-keys.ts`.
+
+## 4. Model Generation (`packages/ai/scripts/generate-models.ts`)
+
+- Add logic to fetch/parse models from the provider source.
+- Map to the standardized `Model` interface.
+
+## 5. Tests (`packages/ai/test/`)
+
+- Always add the provider to `stream.test.ts` with at least one representative model, even if it reuses an existing API impl such as `openai-completions`.
+- Add the provider to the broader matrix where applicable: `tokens.test.ts`, `abort.test.ts`, `empty.test.ts`, `context-overflow.test.ts`, `unicode-surrogate.test.ts`, `tool-call-without-result.test.ts`, `image-tool-result.test.ts`, `total-tokens.test.ts`, `cross-provider-handoff.test.ts`.
+- For `cross-provider-handoff.test.ts`, add at least one provider/model pair. If the provider exposes multiple model families (e.g. GPT and Claude), add at least one pair per family.
+- For non-standard auth, create a utility (e.g. `bedrock-utils.ts`) with credential detection.
+
+## 6. Coding Agent (`packages/coding-agent/`)
+
+- `src/core/model-resolver.ts`: add default model ID to `defaultModelPerProvider`.
+- `src/core/provider-display-names.ts`: add API-key login display name so `/login` and related UI show the provider for built-in API-key auth.
+- `src/cli/args.ts`: add env var documentation.
+- `README.md`: add provider setup instructions.
+- `docs/providers.md`: add setup instructions, env var, and `auth.json` key.
+
+## 7. Documentation
+
+- `packages/ai/README.md`: add to providers table, document options/auth, add env vars.
+- `packages/ai/CHANGELOG.md`: add entry under `## [Unreleased]`.

package/.references/pi/AGENTS.md

@@ -0,0 +1,162 @@
+# Development Rules
+
+## Conversational Style
+
+- Keep answers short and concise
+- No emojis in commits, issues, PR comments, or code
+- No fluff or cheerful filler text (e.g., "Thanks @user" not "Thanks so much @user!")
+- Technical prose only, be direct
+- When the user asks a question, answer it first before making edits or running implementation commands.
+- When responding to user feedback or an analysis, explicitly say whether you agree or disagree before saying what you changed.
+
+## Code Quality
+
+- Read files in full before wide-ranging changes, before editing files you have not fully inspected, and when asked to investigate or audit. Do not rely on search snippets for broad changes.
+- No `any` unless absolutely necessary.
+- Inline single-line helpers that have only one call site.
+- Check node_modules for external API types; don't guess.
+- **No inline imports** (`await import()`, `import("pkg").Type`, dynamic type imports). Top-level imports only.
+- Never remove or downgrade code to fix type errors from outdated deps; upgrade the dep instead.
+- Use only erasable TypeScript syntax (Node strip-only mode) in code checked by the root config (`packages/*/src`, `packages/*/test`, `packages/coding-agent/examples`): no parameter properties, `enum`, `namespace`/`module`, `import =`, `export =`, or other constructs needing JS emit. Use explicit fields with constructor assignments.
+- Always ask before removing functionality or code that appears intentional.
+- Do not preserve backward compatibility unless the user asks for it.
+- Never hardcode key checks (e.g. `matchesKey(keyData, "ctrl+x")`). Add defaults to `DEFAULT_EDITOR_KEYBINDINGS` or `DEFAULT_APP_KEYBINDINGS` so they stay configurable.
+- Never modify `packages/ai/src/models.generated.ts` directly; update `packages/ai/scripts/generate-models.ts` instead, then regenerate. Including the resulting `models.generated.ts` diff is always OK, even if regeneration includes unrelated upstream model metadata changes.
+
+## Commands
+
+- After code changes (not docs): `npm run check` (full output, no tail). Fix all errors, warnings, and infos before committing. Does not run tests.
+- Never run `npm run build` or `npm test` unless requested by the user.
+- Never run the full vitest suite directly: it includes e2e tests that activate when endpoint/auth env vars are present. For all non-e2e tests, run `./test.sh` from the repo root. Otherwise run specific tests from the package root: `node ../../node_modules/vitest/dist/cli.js --run test/specific.test.ts`.
+- If you create or modify a test file, run it and iterate on test or implementation until it passes.
+- For `packages/coding-agent/test/suite/`, use `test/suite/harness.ts` + the faux provider. No real provider APIs, keys, or paid tokens.
+- Put issue-specific regressions under `packages/coding-agent/test/suite/regressions/` named `<issue-number>-<short-slug>.test.ts`.
+- For ad-hoc scripts, `write` them to a temp file (e.g. `/tmp`), run, edit if needed, remove when done. Don't embed multi-line scripts in `bash` commands.
+- Never commit unless the user asks.
+
+## Dependency and Install Security
+
+- Treat npm dep and lockfile changes as reviewed code. Direct external deps stay pinned to exact versions.
+- Hydrate/update locally with `npm install --ignore-scripts`; clean/CI-style with `npm ci --ignore-scripts`. Don't run lifecycle scripts unless the user asks.
+- If dep metadata changes, refresh `package-lock.json` with `npm install --package-lock-only --ignore-scripts`.
+- If `packages/coding-agent/npm-shrinkwrap.json` needs regen, run `node scripts/generate-coding-agent-shrinkwrap.mjs` (verify with `--check` or `npm run check`). New deps with lifecycle scripts require review and an explicit allowlist entry in that script; never add one silently.
+- Pre-commit blocks lockfile commits unless `PI_ALLOW_LOCKFILE_CHANGE=1`. Don't bypass unless the user wants the lockfile change committed.
+
+## Git
+
+Multiple pi sessions may be running in this cwd at the same time, each modifying different files. Git operations that touch unstaged, staged, or untracked files outside your own changes will stomp on other sessions' work. Follow these rules:
+
+Committing:
+
+- Only commit files YOU changed in THIS session.
+- Stage explicit paths (`git add <path1> <path2>`); never `git add -A` / `git add .`.
+- Before committing, run `git status` and verify you are only staging your files.
+- `packages/ai/src/models.generated.ts` may always be included alongside your files.
+- Message format: `{feat,fix,docs}[(ai,tui,agent,coding-agent)]: <commit message> (optionally multiple lines)`. Message is informative and concise.
+
+Never run (destroys other agents' work or bypasses checks):
+
+- `git reset --hard`, `git checkout .`, `git clean -fd`, `git stash`, `git add -A`, `git add .`, `git commit --no-verify`.
+
+If rebase conflicts occur:
+
+- Resolve conflicts only in files you modified.
+- If a conflict is in a file you did not modify, abort and ask the user.
+- Never force push.
+
+## Issues and PRs
+
+See `CONTRIBUTING.md` for the contributor gate (auto-close workflows, `lgtm`/`lgtmi`, quality bar).
+
+When reviewing PRs:
+
+- Do not run `gh pr checkout`, `git switch`, or otherwise move the worktree to the PR branch unless the user explicitly asks.
+- Use `gh pr view`, `gh pr diff`, `gh api`, and local `git show`/`git diff` against fetched refs to inspect PR metadata, commits, and patches without changing branches.
+- If you need PR file contents, fetch/read them into temporary files or use `git show <ref>:<path>` without switching branches.
+
+When creating issues:
+
+- Add `pkg:*` labels for affected packages (`pkg:agent`, `pkg:ai`, `pkg:coding-agent`, `pkg:tui`); use all that apply.
+
+When posting issue/PR comments:
+
+- Write the comment to a temp file and post with `gh issue/pr comment --body-file` (never multi-line markdown via `--body`).
+- Keep comments concise, technical, in the user's tone.
+- End every AI-posted comment with the AI-generated disclaimer line specified by the originating prompt (e.g. `This comment is AI-generated by `/wr``).
+
+When closing issues via commit:
+
+- Include `fixes #<number>` or `closes #<number>` in the message so merging auto-closes the issue. For multiple issues, repeat the keyword per issue (`closes #1, closes #2`); a shared keyword (`closes #1, #2`) only closes the first.
+
+## Testing pi Interactive Mode with tmux
+
+Run the TUI in a controlled terminal (from the repo root):
+
+```bash
+tmux new-session -d -s pi-test -x 80 -y 24
+tmux send-keys -t pi-test "./pi-test.sh" Enter
+sleep 3 && tmux capture-pane -t pi-test -p     # capture after startup
+tmux send-keys -t pi-test "your prompt here" Enter
+tmux send-keys -t pi-test Escape               # special keys (also C-o for ctrl+o, etc.)
+tmux kill-session -t pi-test
+```
+
+## Changelog
+
+Location: `packages/*/CHANGELOG.md` (one per package).
+
+Sections under `## [Unreleased]`: `### Breaking Changes` (API changes requiring migration), `### Added`, `### Changed`, `### Fixed`, `### Removed`.
+
+Rules:
+
+- All new entries go under `## [Unreleased]`. Read the full section first and append to existing subsections; never duplicate them.
+- Released version sections (e.g. `## [0.12.2]`) are immutable; never modify them.
+
+Attribution:
+
+- Internal (from issues): `Fixed foo bar ([#123](https://github.com/earendil-works/pi-mono/issues/123))`
+- External contributions: `Added feature X ([#456](https://github.com/earendil-works/pi-mono/pull/456) by [@username](https://github.com/username))`
+
+## Releasing
+
+**Lockstep versioning**: all packages share one version; every release updates all together. `patch` = fixes + additions, `minor` = breaking changes. No major releases.
+
+1. **Update CHANGELOGs**: ask the user whether they ran the `/cl` prompt on the latest commit on `main`. If not, they must run `/cl` first to audit and update each package's `[Unreleased]` section before releasing.
+
+2. **Local smoke test**: build an unpublished release and smoke test from outside the repo (so it can't resolve workspace files):
+   ```bash
+   npm run release:local -- --out /tmp/pi-local-release --force
+   cd /tmp
+
+   # Node package install smoke tests
+   /tmp/pi-local-release/node/pi --help
+   /tmp/pi-local-release/node/pi --version
+   /tmp/pi-local-release/node/pi --list-models
+   /tmp/pi-local-release/node/pi -p "Say exactly: ok"
+   /tmp/pi-local-release/node/pi
+
+   # Bun binary smoke tests
+   /tmp/pi-local-release/bun/pi --help
+   /tmp/pi-local-release/bun/pi --version
+   /tmp/pi-local-release/bun/pi --list-models
+   /tmp/pi-local-release/bun/pi -p "Say exactly: ok"
+   /tmp/pi-local-release/bun/pi
+   ```
+   Verify both Node and Bun startup, model/account listing, interactive startup, and at least one real prompt with the intended default provider. The bare commands `/tmp/pi-local-release/node/pi` and `/tmp/pi-local-release/bun/pi` start interactive mode; run each in tmux, submit a prompt, and wait for the model reply before considering the interactive smoke test passed. Failures are release blockers unless the user explicitly accepts the risk.
+
+3. **Run the release script**:
+   ```bash
+   PI_ALLOW_LOCKFILE_CHANGE=1 npm_config_min_release_age=0 npm run release:patch    # fixes + additions
+   PI_ALLOW_LOCKFILE_CHANGE=1 npm_config_min_release_age=0 npm run release:minor    # breaking changes
+   ```
+   Use `npm_config_min_release_age=0` only for the release command. The repo's normal npm age gate can otherwise block the release lockfile refresh when the current workspace package version was published recently. Review any lockfile or shrinkwrap diffs the release creates before push.
+
+   The release script bumps all package versions, updates changelogs, regenerates release artifacts, runs `npm run check`, commits `Release vX.Y.Z`, tags `vX.Y.Z`, adds fresh `## [Unreleased]` changelog sections, commits `Add [Unreleased] section for next cycle`, then pushes `main` and the tag. Do not rerun the release script after a tag was pushed.
+
+4. **CI publishes npm packages**: pushing the `vX.Y.Z` tag triggers `.github/workflows/build-binaries.yml`. The `publish-npm` job uses npm trusted publishing through GitHub Actions OIDC with environment `npm-publish`; no local `npm publish`, `npm whoami`, OTP, or WebAuthn flow is required.
+
+5. **If CI publish fails**: inspect the failed `publish-npm` job. The publish helper is idempotent and skips package versions already present on npm, so rerun the tag workflow after fixing CI or transient npm issues. Do not rerun `npm run release:patch` or `npm run release:minor` for the same version.
+
+## User Override
+
+If the user's instructions conflict with any rule in this document, ask for explicit confirmation before overriding. Only then execute their instructions.

package/.references/pi/CONTRIBUTING.md

@@ -0,0 +1,102 @@
+# Contributing to pi
+
+This guide exists to save both sides time.
+
+## Philosophy
+
+First things first: **pi's core is minimal**.
+
+If your feature does not belong in the core, it should be an extension. PRs that bloat the core will likely be rejected.
+
+Pi's core exists to be minimal and to be extensible so that it can be influenced and manipulated by extensions.  Even hook points for extensions however should be well considered and discussed to avoid adding unmaintainable bloat and complex interactions.
+
+## The One Rule
+
+**You must understand your code.** If you cannot explain what your changes do and how they interact with the rest of the system, your PR will be closed.
+
+Using AI to write code is fine. Submitting AI-generated slop without understanding it is not.
+
+If you use an agent, run it from the `pi` root directory so it picks up `AGENTS.md` automatically. Your agent must follow the rules and guidelines in that file.
+
+## Contribution Gate
+
+All issues and PRs from new contributors are auto-closed by default.
+
+Issues submitted Friday through Sunday are not guaranteed to be reviewed.  If something is urgent, ask on Discord: https://discord.com/invite/3cU7Bz4UPx
+
+Maintainers review auto-closed issues daily and reopen worthwhile ones. Issues that do not meet the quality bar below will not be reopened or receive a reply.
+
+Approval happens through maintainer replies on issues:
+
+- `lgtmi`: your future issues will not be auto-closed
+- `lgtm`: your future issues and PRs will not be auto-closed
+
+`lgtmi` does not grant rights to submit PRs. Only `lgtm` grants rights to submit PRs.
+
+## Quality Bar For Issues
+
+If you open an issue, you must use one of the two GitHub issue templates.
+
+If you open an issue, keep it short, concrete, and worth reading.
+
+- Keep it concise. If it does not fit on one screen, it is too long.
+- Write in your own voice (do not use an LLM to generate text, if you must, follow up with a clearly AI labeled comment).
+- State the bug or request clearly.
+- Explain why it matters.
+- If you want to implement the change yourself, say so.
+
+If the issue is real and written well, a maintainer may reopen it, reply `lgtmi`, or reply `lgtm`.
+
+## Blocking
+
+If you ignore this document twice, or if you spam the tracker with agent-generated issues, your GitHub account will be permanently blocked.
+
+If you send a large volume of issues through automation, your GitHub account will be permanently blocked. No taksies backsies.
+
+## Before Submitting a PR
+
+Do not open a PR unless you have already been approved with `lgtm`.
+
+Before submitting a PR:
+
+```bash
+npm run check
+./test.sh
+```
+
+Both must pass.
+
+Do not edit `CHANGELOG.md`. Changelog entries are added by maintainers.
+
+If you are adding a new provider to `packages/ai`, see `AGENTS.md` for required tests.
+
+## Questions?
+
+Ask on [Discord](https://discord.com/invite/nKXTsAcmbT).
+
+## FAQ
+
+### Why are new issues and PRs auto-closed?
+
+pi receives more issues than the maintainers can responsibly review in real time. Many reports do not meet the quality bar in this guide or do not follow CONTRIBUTING.md. Some are slung at the repository mindlessly via an agent instead of being reviewed and shaped by the person submitting them. Auto-closing creates a buffer so maintainers can review the tracker on their own schedule and reopen the issues that meet the quality bar.
+
+### Why are weekend issues lower priority?
+
+We triage the tracker during working hours. That means more issues can accumulate over the weekend. Anything submitted Friday through Sunday may be missed or given lower priority in the Monday review queue. If a problem is urgent, ask on Discord and include the short version, a repro, and the relevant logs.
+
+### Why do some issues get no reply?
+
+A reply is maintenance work too. Low-signal issues, unclear reports, duplicates, and issues that do not follow this guide may be closed without discussion. This keeps time available for reproducible bugs, thoughtful requests, and contributors who have done the work to make their report actionable.
+
+### Why not let AI triage everything?
+
+AI can help group duplicates, summarize reports, and spot missing information. It is not trusted to make final maintainer decisions. Polished AI-generated issues can still be wrong, misleading, or expensive to investigate. Human review remains the final gate.
+
+### Is this hostile to contributors?
+
+No. It is a guardrail against burnout and tracker spam. Short, concrete, reproducible issues are welcome. Thoughtful contributions are welcome. Automated slop, entitlement, and large volumes of low-effort reports are not.
+
+## Where can I learn about plans?
+
+Earendil uses RFCs to discuss larger changes.  Not all of them are public, but
+quite a few are.  They can be found at [rfc.earendil.com](https://rfc.earendil.com/keyword/pi/).