one-code-extension 0.1.4 → 0.3.0

package/extensions/worktree/rewrite.ts

@@ -20,32 +20,48 @@ export function shellQuote(path: string): string {
 	return `'${path.replace(/'/g, "'\\''")}'`;
 }
 
+
 /**
- * Key under which a worktree-rewritten bash call preserves the model's original
- * (pre-`cd`-wrapper) command. The permission matcher reads it so allow/ask/deny
- * rules are evaluated against what the model actually asked for, not the
- * `cd '<wt>' && (…)` wrapper (which starts with `cd` and matches no Bash rule).
- * The classifier and safety floor still see the wrapped `input.command`, whose
- * `cd` makes containment resolve inside the worktree — see docs/decisions/worktree.md.
+ * Mutates `input` in place so the call runs inside the worktree. For bash,
+ * returns the model's ORIGINAL command (pre-`cd`-wrapper) so the caller can
+ * publish it over `ORIGINAL_COMMAND_CHANNEL` keyed by the call id: the
+ * permission matcher evaluates rules against what the model asked for, not
+ * the wrapper (which starts with `cd` and matches no Bash rule), while the
+ * classifier and safety floor keep reading the wrapped `input.command`, whose
+ * `cd` makes containment resolve inside the worktree —
+ * docs/decisions/code-review-remediation.md ("Worktree vs. permission rules").
+ * The original is deliberately NOT stored in `input`: a key there is
+ * model-writable (lib/original-command.ts).
  */
-export const ORIGINAL_COMMAND_KEY = "__ccOriginalCommand";
-
-/** Mutates `input` in place so the call runs inside the worktree. */
-export function rewriteToolInput(toolName: string, input: Record<string, unknown>, worktreePath: string): void {
+export function rewriteToolInput(
+	toolName: string,
+	input: Record<string, unknown>,
+	worktreePath: string,
+): { originalCommand?: string } {
 	if (toolName === "bash") {
 		if (typeof input.command === "string") {
-			input[ORIGINAL_COMMAND_KEY] = input.command;
-			input.command = `cd ${shellQuote(worktreePath)} && (${input.command}\n)`;
+			const originalCommand = input.command;
+			input.command = `cd ${shellQuote(worktreePath)} && (${originalCommand}\n)`;
+			return { originalCommand };
 		}
-		return;
+		return {};
 	}
-	if (!PATH_TOOLS.has(toolName)) return;
+	if (!PATH_TOOLS.has(toolName)) return {};
 
-	if (typeof input.path === "string" && input.path.length > 0) {
-		if (!isAbsolute(input.path)) input.path = resolve(worktreePath, input.path);
+	// Rewrite whichever field carries the path — `path` for pi's built-ins,
+	// `file_path`/`notebook_path` for Claude Code-shaped calls — so a
+	// notebook_edit using `notebook_path` still lands inside the worktree
+	// instead of the shared checkout (code-review).
+	const pathField = (["path", "file_path", "notebook_path"] as const).find(
+		(field) => typeof input[field] === "string" && (input[field] as string).length > 0,
+	);
+	if (pathField) {
+		const value = input[pathField] as string;
+		if (!isAbsolute(value)) input[pathField] = resolve(worktreePath, value);
 	} else if (DEFAULTS_TO_CWD.has(toolName)) {
 		input.path = worktreePath;
 	}
+	return {};
 }
 
 /** Validates an EnterWorktree name: /-separated segments of [A-Za-z0-9._-], ≤64 chars total. */

package/package.json

@@ -1,7 +1,7 @@
 {
 	"name": "one-code-extension",
-	"version": "0.1.4",
-	"description": "One Code as a pi package \u2014 the Claude Code experience on your own pi install: ported system prompt, Claude-Code-format permissions, .claude/ compatibility, ToolSearch-style deferred tools, and system-reminder steering. For the bundled app, install `@one-ai/one-code` instead.",
+	"version": "0.3.0",
+	"description": "One Code as a pi package — the Claude Code experience on your own pi install: ported system prompt, Claude-Code-format permissions, .claude/ compatibility, ToolSearch-style deferred tools, and system-reminder steering. For the bundled app, install `@one-ai/one-code` instead.",
 	"keywords": [
 		"pi",
 		"pi-package",
@@ -28,6 +28,7 @@
 		"extensions": [
 			"extensions/branding/index.ts",
 			"extensions/claude-compat/index.ts",
+			"extensions/context-budget/index.ts",
 			"extensions/system-reminder/index.ts",
 			"extensions/claude-context/index.ts",
 			"extensions/hooks/index.ts",
@@ -46,8 +47,15 @@
 			"extensions/subagents/index.ts",
 			"extensions/workflow/index.ts",
 			"extensions/effort/index.ts",
+			"extensions/spinner/index.ts",
+			"extensions/model-default/index.ts",
+			"extensions/footer/index.ts",
+			"extensions/turn-duration/index.ts",
+			"extensions/interrupted/index.ts",
+			"extensions/recap/index.ts",
 			"extensions/exit/index.ts",
-			"extensions/todo/index.ts",
+			"extensions/init/index.ts",
+			"extensions/clear/index.ts",
 			"extensions/tasks/index.ts",
 			"extensions/plan-mode/index.ts",
 			"extensions/notebook/index.ts",
@@ -55,6 +63,7 @@
 			"extensions/web-fetch/index.ts",
 			"extensions/lsp/index.ts",
 			"extensions/mcp/index.ts",
+			"extensions/doctor/index.ts",
 			"extensions/context-management/index.ts",
 			"extensions/compaction/index.ts",
 			"extensions/system-prompt/index.ts"
@@ -66,30 +75,31 @@
 	"files": [
 		"extensions/",
 		"agents/",
+		"skills/",
 		"themes/",
 		"types/",
 		"README.md",
 		"LICENSE",
-		"docs/decisions.md",
-		"docs/decisions/"
+		"docs/guide/"
 	],
 	"scripts": {
 		"typecheck": "tsc --noEmit",
-		"test": "vitest run"
+		"test": "vitest run",
+		"gen:model-facts": "node scripts/gen-model-facts.mjs"
 	},
 	"dependencies": {
 		"@modelcontextprotocol/sdk": "^1.30.0",
 		"@mozilla/readability": "^0.6.0",
 		"acorn": "^8.18.0",
 		"linkedom": "^0.18.13",
-		"pi-web-search": "^1.3.1",
+		"pi-web-search": "^1.5.0",
 		"turndown": "^7.2.4",
 		"typebox": "^1.3.7"
 	},
 	"devDependencies": {
-		"@earendil-works/pi-agent-core": "^0.84.1",
-		"@earendil-works/pi-ai": "^0.84.1",
-		"@earendil-works/pi-coding-agent": "^0.84.1",
+		"@earendil-works/pi-agent-core": "^0.85.1",
+		"@earendil-works/pi-ai": "^0.85.1",
+		"@earendil-works/pi-coding-agent": "^0.85.1",
 		"@types/node": "^26.1.2",
 		"@types/turndown": "^5.0.6",
 		"typescript": "^5.6.0",

package/skills/code-review/SKILL.md

@@ -0,0 +1,165 @@
+---
+name: code-review
+description: >
+  Review the current diff, or a PR number/branch/path target, for correctness
+  bugs and reuse/simplification/efficiency cleanups. Pass --comment to post
+  findings as inline PR comments, or --fix to apply the findings to the working
+  tree after the review. Raise the reasoning effort (/effort) for broader,
+  recall-biased coverage; lower it for fewer, high-confidence findings.
+---
+
+`medium effort → 3+5 angles × 6 candidates → 1-vote verify → ≤8 findings`
+
+You are reviewing for **precision**: every finding you surface should be one a
+maintainer would act on. If the session is running at a higher reasoning effort,
+shift toward **recall** — catch every real bug a careful reviewer would catch in
+one sitting, err on the side of surfacing, and raise the finding cap and the
+number of finder angles accordingly.
+
+## Phase 0 — Gather the diff
+
+Run `git diff @{upstream}...HEAD` (or `git diff main...HEAD` / `git diff HEAD~1`
+if there's no upstream) to get the unified diff under review. If there are
+uncommitted changes, or the range diff is empty, also run `git diff HEAD` and
+include the working-tree changes in scope — the review often runs before the
+commit. If a PR number, branch name, or file path was passed as an argument,
+review that target instead. Treat this diff as the review scope.
+
+## Phase 1 — Find candidates (3 correctness angles + 3 cleanup angles + 1 altitude angle + 1 conventions angle, up to 6 each)
+
+Run **8 independent finder angles** via the Agent tool. Each
+surfaces **up to 6 candidate findings** with `file`, `line`, a one-line
+`summary`, and a concrete `failure_scenario`. If the Agent tool is not available
+in your current tool set, do not error — perform each angle (and each
+verification) yourself, sequentially, in this context.
+
+### Angle A — line-by-line diff scan
+
+Read every hunk in the diff, line by line. Then Read the enclosing function for
+each hunk — bugs in unchanged lines of a touched function are in scope (the PR
+re-exposes or fails to fix them). For every line ask: what input, state, timing,
+or platform makes this line wrong? Look for inverted/wrong conditions,
+off-by-one, null/undefined deref, missing `await`, falsy-zero checks,
+wrong-variable copy-paste, error swallowed in catch, unescaped regex metachars.
+
+### Angle B — removed-behavior auditor
+
+For every line the diff DELETES or replaces, name the invariant or behavior it
+enforced, then search the new code for where that invariant is re-established.
+If you can't find it, that's a candidate: a removed guard, a dropped error
+path, a narrowed validation, a deleted test that was covering a real case.
+
+### Angle C — cross-file tracer
+
+For each function the diff changes, find its callers (Grep for the symbol) and
+check whether the change breaks any call site: a new precondition, a changed
+return shape, a new exception, a timing/ordering dependency. Also check callees:
+does a parallel change in the same PR make a call unsafe?
+
+### Reuse
+
+The angles above hunt for bugs; this one and the next two hunt for cleanup in
+the changed code. Flag new code that re-implements something the codebase
+already has — Grep shared/utility modules and files adjacent to the change,
+and name the existing helper to call instead.
+
+### Simplification
+
+Flag unnecessary complexity the diff adds: redundant or derivable state,
+copy-paste with slight variation, deep nesting, dead code left behind. Name
+the simpler form that does the same job.
+
+### Efficiency
+
+Flag wasted work the diff introduces: redundant computation or repeated I/O,
+independent operations run sequentially, blocking work added to startup or
+hot paths. Also flag long-lived objects built from closures or captured
+environments — they keep the entire enclosing scope alive for the object's
+lifetime (a memory leak when that scope holds large values); prefer a
+class/struct that copies only the fields it needs. Name the cheaper
+alternative.
+
+### Altitude
+
+Check that each change is implemented at the right depth, not as a fragile
+bandaid. Special cases layered on shared infrastructure are a sign the fix
+isn't deep enough — prefer generalizing the underlying mechanism over adding
+special cases.
+
+### Conventions (CLAUDE.md)
+
+Find the CLAUDE.md files that govern the changed code: the user-level
+~/.claude/CLAUDE.md, the repo-root CLAUDE.md, plus any CLAUDE.md or
+CLAUDE.local.md in a directory that is an ancestor of a changed file (a
+directory's CLAUDE.md only applies to files at or below it). Read each one
+that exists, then check the diff for clear violations of the rules they state.
+
+Only flag a violation when you can quote the exact rule and the exact line
+that breaks it — no style preferences, no vague "spirit of the doc"
+inferences. In the finding, name the CLAUDE.md path and quote the rule so the
+report can cite it. If no CLAUDE.md applies, return nothing for this angle.
+
+Cleanup, altitude, and conventions candidates use the same
+`file`/`line`/`summary` shape; in `failure_scenario`, state the concrete
+cost (what is duplicated, wasted, harder to maintain, or which CLAUDE.md rule
+is broken) instead of a crash. Correctness bugs always outrank cleanup,
+altitude, and conventions findings when the output cap forces a cut.
+
+Pass every candidate with a nameable failure scenario through — finders that
+silently drop half-believed candidates bypass the verify step and are the
+dominant cause of misses.
+
+## Phase 2 — Verify (1-vote, 3-state)
+
+Dedup candidates that point at the same line/mechanism, keeping the one with
+the most concrete failure scenario. For each remaining candidate, run **one
+verifier** via the Agent tool: give it the diff, the relevant
+file(s), and the candidate, and have it return exactly one of:
+
+- **CONFIRMED** — can name the inputs/state that trigger it and the wrong
+  output or crash. Quote the line.
+- **PLAUSIBLE** — mechanism is real, trigger is uncertain (timing, env,
+  config). State what would confirm it.
+- **REFUTED** — factually wrong (code doesn't say that) or guarded elsewhere.
+  Quote the line that proves it.
+
+Keep candidates where the vote is CONFIRMED or PLAUSIBLE.
+
+## Output
+
+Return findings as a JSON array of at most 8 objects (raise the cap when running
+at higher effort):
+
+```json
+[
+  {
+    "file": "path/to/file.ext",
+    "line": 123,
+    "summary": "one-sentence statement of the bug",
+    "failure_scenario": "concrete inputs/state → wrong output/crash"
+  }
+]
+```
+
+Ranked most-severe first. If more than the cap survive, keep the most severe. If
+nothing survives verification, return `[]`.
+
+## Arguments and flags
+
+Read the invocation arguments and adjust accordingly:
+
+- **A target** (`<pr#>`, `<branch>`, or `<path>`) replaces "the current diff" as
+  the review scope in Phase 0.
+- **`--comment`** — after producing the findings list, if the review target is a
+  GitHub PR, post each finding as an inline PR comment (one call per finding;
+  include a suggestion block only when it fully fixes the issue). Prefer a
+  GitHub inline-comment MCP tool if one is connected this session; otherwise use
+  `gh api repos/{owner}/{repo}/pulls/{pr}/comments`. If the target is not a PR,
+  print the findings to the terminal and note that `--comment` was ignored.
+- **`--fix`** — after producing the findings list, apply the findings to the
+  working tree instead of stopping at the report: fix each one directly —
+  correctness bugs and reuse/simplification/efficiency cleanups alike. Skip any
+  finding whose fix would change intended behavior, require changes well outside
+  the reviewed diff, or that you judge to be a false positive — note the skip
+  rather than arguing with it. Finish with a brief summary of what was fixed and
+  what was skipped.

package/skills/fewer-permission-prompts/SKILL.md

@@ -0,0 +1,61 @@
+---
+name: fewer-permission-prompts
+description: >
+  Scan your session transcripts for common read-only Bash and MCP tool calls,
+  then add a prioritized allowlist to One Code's per-repo settings to reduce
+  permission prompts.
+---
+
+# Fewer Permission Prompts
+
+Look through my transcripts' MCP and bash tool calls, and based on those, make a prioritized list of patterns that I should add to my permission allowlist to reduce permission prompts. Focus on read-only commands.
+
+The format for permissions is: `Bash(foo*)`, `Bash(foo)`, `Bash(foo bar *)`, `mcp__slack__slack_read_thread`, etc. Claude Code's PascalCase tool names are accepted too and mapped automatically.
+
+Then, add these to One Code's per-repo settings at `~/.onecode/projects/<slug>/settings.json` under `permissions.allow`. Never write to `~/.claude` — that is Claude Code's directory and One Code treats it as read-only.
+
+## Steps
+
+1. **Locate transcripts.** One Code / pi session transcripts live under the agent state dir at `~/.onecode/agent/sessions/<sanitized-cwd>/*.jsonl` (the base honours `PI_CODING_AGENT_DIR`, which the bundled app sets to `~/.onecode/agent`; a stock pi install uses its own agent dir). Each line is a JSON object. Tool calls appear as assistant messages whose content carries tool-call entries: a tool name (e.g. `Bash`, `mcp__slack__slack_read_thread`) and, for a shell tool, the command string in its input.
+
+   Scan the recent transcripts across the sessions dir — not just the current project — so the allowlist reflects your actual usage. Cap the scan at a reasonable number of recent sessions (e.g. 50 most-recently-modified JSONL files) so this stays fast.
+
+2. **Extract tool-call frequencies.**
+   - For shell (`Bash`) calls: parse the command, take the leading command token (handling `sudo`, `timeout`, pipes, `&&`, env-var prefixes). Record the command + first subcommand pair (e.g. `git status`, `gh pr view`, `ls`, `cat`).
+   - For MCP calls: record the full tool name (e.g. `mcp__slack__slack_read_thread`).
+   - Count occurrences across the scanned transcripts.
+
+3. **Filter to read-only.** Keep only commands that don't mutate state. Examples of read-only: `ls`, `cat`, `pwd`, `git status`, `git log`, `git diff`, `git show`, `git branch`, `rg`, `grep`, `find`, `head`, `tail`, `wc`, `file`, `which`, `echo`, `date`, `gh pr view`, `gh pr list`, `gh pr diff`, `gh issue view`, `gh issue list`, `gh run list`, `gh run view`, `gh api` (GET), `docker ps`, `docker logs`, `kubectl get`, `kubectl describe`, `ps`, `top`, `df`, `du`, `env`, `printenv`, any MCP tool with `read`/`get`/`list`/`search`/`view` in its name.
+
+   Drop anything that writes, deletes, renames, pushes, merges, installs, or runs a build/test that has side effects. When in doubt, leave it out.
+
+   **Never allowlist a pattern that grants arbitrary code execution.** A wildcard rule for any of these (e.g. `Bash(python3:*)`) is equivalent to allowing arbitrary code execution. This list is not exhaustive — apply the same rule to anything in the same category:
+   - Interpreters: `python`/`python3`, `node`, `bun`, `deno`, `ruby`, `perl`, `php`, `lua`, etc.
+   - Shells: `bash`, `sh`, `zsh`, `fish`, `eval`, `exec`, `ssh`, etc.
+   - Package runners: `npx`, `bunx`, `uvx`, `uv run`, etc.
+   - Task-runner wildcards: `npm run *`, `yarn run *`, `pnpm run *`, `bun run *`, `make *`, `just *`, `cargo run *`, `go run *`, etc. — an exact `Bash(npm run typecheck)` is fine, `Bash(npm run *)` is not
+   - `gh api *`, `docker run`/`exec`, `kubectl exec`, `sudo`, and similar
+
+4. **Drop commands One Code already auto-allows.** One Code's auto-mode floor already treats common read-only commands as safe, so they never prompt in auto mode and don't need an allowlist entry — plain `cat`, `ls`, `git status`, `grep`, and the like. If you see these in the transcripts, don't bother suggesting them. When you are unsure whether a command is already covered, it is safe to include it anyway: a redundant `permissions.allow` entry is harmless, whereas a genuinely useful allow left out keeps prompting you.
+
+5. **Pick the pattern form.** Use the narrowest pattern that still covers the observed usage:
+   - If you run many variants (`git log`, `git log --oneline`, `git log main..HEAD`): use `Bash(git log *)` — note the space before `*`, which is required for prefix matching to work correctly.
+   - If a single exact invocation is common: use `Bash(foo)` with no wildcard.
+   - For MCP: use the full tool name verbatim (no wildcard needed; they're already specific).
+   - Never widen a pattern to the point that it conflicts with the rules above (no arbitrary code execution, no mutation/side effects).
+
+6. **Prioritize.** Rank by count descending. Drop anything that appeared fewer than ~3 times — not worth the allowlist entry. Cap the list at the top ~20 so you can skim it.
+
+7. **Present the prioritized list to the user** as a markdown table with columns: rank, pattern, count, one-line description. Example:
+
+   | # | Pattern | Count | Notes |
+   |---|---------|-------|-------|
+   | 1 | `Bash(git status *)` | 142 | repo status checks |
+   | 2 | `Bash(gh pr view *)` | 87 | PR inspection |
+   | 3 | `mcp__slack__slack_read_thread` | 54 | Slack thread reads |
+
+8. **Merge into the per-repo settings** at `~/.onecode/projects/<slug>/settings.json` (not `~/.onecode/settings.json`, not anything under `~/.claude`). Create the file if it doesn't exist. Preserve existing keys and existing entries in `permissions.allow`; de-duplicate against what's already there; don't remove anything; don't reorder unrelated fields.
+
+9. **Report back.** Tell the user what you added (count + a few examples), what was already in the allowlist, and what you skipped and why (e.g. "dropped `rm` and `git push` — not read-only; dropped `cat`/`ls`/`git status` — already auto-allowed, no rule needed").
+
+Do not add anything to `permissions.deny` or `permissions.ask`. Do not touch any other settings field.

package/skills/security-review/SKILL.md

@@ -0,0 +1,178 @@
+---
+name: security-review
+description: >
+  Complete a security review of the pending changes on the current branch — a
+  focused, high-confidence hunt for exploitable vulnerabilities newly introduced
+  by the diff, reported as a severity-ranked markdown briefing.
+---
+
+You are a senior security engineer conducting a focused security review of the changes on this branch.
+
+## Phase 0 — Gather the changes
+
+Run these commands and treat their combined output as the review scope:
+
+- `git status`
+- `git diff --name-only origin/HEAD...` — files modified
+- `git log --no-decorate origin/HEAD...` — commits
+- `git diff origin/HEAD...` — the full diff
+
+Review the complete diff. This contains all code changes in the PR.
+
+OBJECTIVE:
+Perform a security-focused code review to identify HIGH-CONFIDENCE security vulnerabilities that could have real exploitation potential. This is not a general code review - focus ONLY on security implications newly added by this PR. Do not comment on existing security concerns.
+
+CRITICAL INSTRUCTIONS:
+1. MINIMIZE FALSE POSITIVES: Only flag issues where you're >80% confident of actual exploitability
+2. AVOID NOISE: Skip theoretical issues, style concerns, or low-impact findings
+3. FOCUS ON IMPACT: Prioritize vulnerabilities that could lead to unauthorized access, data breaches, or system compromise
+4. EXCLUSIONS: Do NOT report the following issue types:
+   - Denial of Service (DOS) vulnerabilities, even if they allow service disruption
+   - Secrets or sensitive data stored on disk (these are handled by other processes)
+   - Rate limiting or resource exhaustion issues
+
+SECURITY CATEGORIES TO EXAMINE:
+
+**Input Validation Vulnerabilities:**
+- SQL injection via unsanitized user input
+- Command injection in system calls or subprocesses
+- XXE injection in XML parsing
+- Template injection in templating engines
+- NoSQL injection in database queries
+- Path traversal in file operations
+
+**Authentication & Authorization Issues:**
+- Authentication bypass logic
+- Privilege escalation paths
+- Session management flaws
+- JWT token vulnerabilities
+- Authorization logic bypasses
+
+**Crypto & Secrets Management:**
+- Hardcoded API keys, passwords, or tokens
+- Weak cryptographic algorithms or implementations
+- Improper key storage or management
+- Cryptographic randomness issues
+- Certificate validation bypasses
+
+**Injection & Code Execution:**
+- Remote code execution via deseralization
+- Pickle injection in Python
+- YAML deserialization vulnerabilities
+- Eval injection in dynamic code execution
+- XSS vulnerabilities in web applications (reflected, stored, DOM-based)
+
+**Data Exposure:**
+- Sensitive data logging or storage
+- PII handling violations
+- API endpoint data leakage
+- Debug information exposure
+
+Additional notes:
+- Even if something is only exploitable from the local network, it can still be a HIGH severity issue
+
+ANALYSIS METHODOLOGY:
+
+Phase 1 - Repository Context Research (Use file search tools):
+- Identify existing security frameworks and libraries in use
+- Look for established secure coding patterns in the codebase
+- Examine existing sanitization and validation patterns
+- Understand the project's security model and threat model
+
+Phase 2 - Comparative Analysis:
+- Compare new code changes against existing security patterns
+- Identify deviations from established secure practices
+- Look for inconsistent security implementations
+- Flag code that introduces new attack surfaces
+
+Phase 3 - Vulnerability Assessment:
+- Examine each modified file for security implications
+- Trace data flow from user inputs to sensitive operations
+- Look for privilege boundaries being crossed unsafely
+- Identify injection points and unsafe deserialization
+
+REQUIRED OUTPUT FORMAT:
+
+You MUST output your findings in markdown. The markdown output should contain the file, line number, severity, category (e.g. `sql_injection` or `xss`), description, exploit scenario, and fix recommendation.
+
+For example:
+
+# Vuln 1: XSS: `foo.py:42`
+
+* Severity: High
+* Description: User input from `username` parameter is directly interpolated into HTML without escaping, allowing reflected XSS attacks
+* Exploit Scenario: Attacker crafts URL like /bar?q=<script>alert(document.cookie)</script> to execute JavaScript in victim's browser, enabling session hijacking or data theft
+* Recommendation: Use Flask's escape() function or Jinja2 templates with auto-escaping enabled for all user inputs rendered in HTML
+
+SEVERITY GUIDELINES:
+- **HIGH**: Directly exploitable vulnerabilities leading to RCE, data breach, or authentication bypass
+- **MEDIUM**: Vulnerabilities requiring specific conditions but with significant impact
+- **LOW**: Defense-in-depth issues or lower-impact vulnerabilities
+
+CONFIDENCE SCORING:
+- 0.9-1.0: Certain exploit path identified, tested if possible
+- 0.8-0.9: Clear vulnerability pattern with known exploitation methods
+- 0.7-0.8: Suspicious pattern requiring specific conditions to exploit
+- Below 0.7: Don't report (too speculative)
+
+FINAL REMINDER:
+Focus on HIGH and MEDIUM findings only. Better to miss some theoretical issues than flood the report with false positives. Each finding should be something a security engineer would confidently raise in a PR review.
+
+FALSE POSITIVE FILTERING:
+
+> You do not need to run commands to reproduce the vulnerability, just read the code to determine if it is a real vulnerability. Do not use the bash tool or write to any files.
+>
+> HARD EXCLUSIONS - Automatically exclude findings matching these patterns:
+> 1. Denial of Service (DOS) vulnerabilities or resource exhaustion attacks.
+> 2. Secrets or credentials stored on disk if they are otherwise secured.
+> 3. Rate limiting concerns or service overload scenarios.
+> 4. Memory consumption or CPU exhaustion issues.
+> 5. Lack of input validation on non-security-critical fields without proven security impact.
+> 6. Input sanitization concerns for GitHub Action workflows unless they are clearly triggerable via untrusted input.
+> 7. A lack of hardening measures. Code is not expected to implement all security best practices, only flag concrete vulnerabilities.
+> 8. Race conditions or timing attacks that are theoretical rather than practical issues. Only report a race condition if it is concretely problematic.
+> 9. Vulnerabilities related to outdated third-party libraries. These are managed separately and should not be reported here.
+> 10. Memory safety issues such as buffer overflows or use-after-free-vulnerabilities are impossible in rust. Do not report memory safety issues in rust or any other memory safe languages.
+> 11. Files that are only unit tests or only used as part of running tests.
+> 12. Log spoofing concerns. Outputting un-sanitized user input to logs is not a vulnerability.
+> 13. SSRF vulnerabilities that only control the path. SSRF is only a concern if it can control the host or protocol.
+> 14. Including user-controlled content in AI system prompts is not a vulnerability.
+> 15. Regex injection. Injecting untrusted content into a regex is not a vulnerability.
+> 16. Regex DOS concerns.
+> 16. Insecure documentation. Do not report any findings in documentation files such as markdown files.
+> 17. A lack of audit logs is not a vulnerability.
+>
+> PRECEDENTS -
+> 1. Logging high value secrets in plaintext is a vulnerability. Logging URLs is assumed to be safe.
+> 2. UUIDs can be assumed to be unguessable and do not need to be validated.
+> 3. Environment variables and CLI flags are trusted values. Attackers are generally not able to modify them in a secure environment. Any attack that relies on controlling an environment variable is invalid.
+> 4. Resource management issues such as memory or file descriptor leaks are not valid.
+> 5. Subtle or low impact web vulnerabilities such as tabnabbing, XS-Leaks, prototype pollution, and open redirects should not be reported unless they are extremely high confidence.
+> 6. React and Angular are generally secure against XSS. These frameworks do not need to sanitize or escape user input unless it is using dangerouslySetInnerHTML, bypassSecurityTrustHtml, or similar methods. Do not report XSS vulnerabilities in React or Angular components or tsx files unless they are using unsafe methods.
+> 7. Most vulnerabilities in github action workflows are not exploitable in practice. Before validating a github action workflow vulnerability ensure it is concrete and has a very specific attack path.
+> 8. A lack of permission checking or authentication in client-side JS/TS code is not a vulnerability. Client-side code is not trusted and does not need to implement these checks, they are handled on the server-side. The same applies to all flows that send untrusted data to the backend, the backend is responsible for validating and sanitizing all inputs.
+> 9. Only include MEDIUM findings if they are obvious and concrete issues.
+> 10. Most vulnerabilities in ipython notebooks (*.ipynb files) are not exploitable in practice. Before validating a notebook vulnerability ensure it is concrete and has a very specific attack path where untrusted input can trigger the vulnerability.
+> 11. Logging non-PII data is not a vulnerability even if the data may be sensitive. Only report logging vulnerabilities if they expose sensitive information such as secrets, passwords, or personally identifiable information (PII).
+> 12. Command injection vulnerabilities in shell scripts are generally not exploitable in practice since shell scripts generally do not run with untrusted user input. Only report command injection vulnerabilities in shell scripts if they are concrete and have a very specific attack path for untrusted input.
+>
+> SIGNAL QUALITY CRITERIA - For remaining findings, assess:
+> 1. Is there a concrete, exploitable vulnerability with a clear attack path?
+> 2. Does this represent a real security risk vs theoretical best practice?
+> 3. Are there specific code locations and reproduction steps?
+> 4. Would this finding be actionable for a security team?
+>
+> For each finding, assign a confidence score from 1-10:
+> - 1-3: Low confidence, likely false positive or noise
+> - 4-6: Medium confidence, needs investigation
+> - 7-10: High confidence, likely true vulnerability
+
+START ANALYSIS:
+
+Begin your analysis now. Do this in 3 steps:
+
+1. Spawn one subagent via the Agent tool to identify vulnerabilities. Have it use the repository exploration tools to understand the codebase context, then analyze the PR changes for security implications. In the prompt for this subagent, include all of the above. If the Agent tool is not available in your current tool set, do this step yourself in this context instead.
+2. Then for each vulnerability the first step identified, spawn a new subagent via the Agent tool to filter out false-positives. Launch these as parallel Agent subagents. In the prompt for each, include everything in the "FALSE POSITIVE FILTERING" instructions. (Without the Agent tool, run this filtering pass yourself.)
+3. Filter out any vulnerabilities where the filtering step reported a confidence less than 8.
+
+Your final reply must contain the markdown report and nothing else.

package/skills/simplify/SKILL.md

@@ -0,0 +1,70 @@
+---
+name: simplify
+description: >
+  Review the changed code for reuse, simplification, efficiency, and altitude
+  cleanups, then apply the fixes. Quality only — it does not hunt for bugs; use
+  code-review for that.
+---
+
+`/simplify → 4 cleanup agents in parallel → apply the fixes`
+
+You are improving the quality of the changed code, not hunting for bugs. Review
+it for reuse, simplification, efficiency, and altitude issues, then fix what you
+find. Do not look for correctness bugs — that is what `/code-review` is for.
+
+## Phase 0 — Gather the diff
+
+Run `git diff @{upstream}...HEAD` (or `git diff main...HEAD` / `git diff HEAD~1`
+if there's no upstream) to get the unified diff under review. If there are
+uncommitted changes, or the range diff is empty, also run `git diff HEAD` and
+include the working-tree changes in scope — the review often runs before the
+commit. If a PR number, branch name, or file path was passed as an argument,
+review that target instead. Treat this diff as the review scope.
+
+## Phase 1 — Review (4 cleanup agents in parallel)
+
+Launch **4 independent review agents** via the Agent tool, all in a
+single message so they run concurrently. Pass each agent the diff and one of
+the four angles below. Each returns its findings with `file`, `line`, a
+one-line `summary`, and the concrete cost (what is duplicated, wasted, or
+harder to maintain). If the Agent tool is not available in your current tool
+set, do not error — work through all four angles yourself, sequentially, in
+this same context.
+
+### Reuse
+
+Flag new code that re-implements something the codebase
+already has — Grep shared/utility modules and files adjacent to the change,
+and name the existing helper to call instead.
+
+### Simplification
+
+Flag unnecessary complexity the diff adds: redundant or derivable state,
+copy-paste with slight variation, deep nesting, dead code left behind. Name
+the simpler form that does the same job.
+
+### Efficiency
+
+Flag wasted work the diff introduces: redundant computation or repeated I/O,
+independent operations run sequentially, blocking work added to startup or
+hot paths. Also flag long-lived objects built from closures or captured
+environments — they keep the entire enclosing scope alive for the object's
+lifetime (a memory leak when that scope holds large values); prefer a
+class/struct that copies only the fields it needs. Name the cheaper
+alternative.
+
+### Altitude
+
+Check that each change is implemented at the right depth, not as a fragile
+bandaid. Special cases layered on shared infrastructure are a sign the fix
+isn't deep enough — prefer generalizing the underlying mechanism over adding
+special cases.
+
+## Phase 2 — Apply the fixes
+
+Wait for all four agents to complete, dedup findings that point at the same
+line or mechanism, and fix each remaining one directly. Skip any finding whose
+fix would change intended behavior, require changes well outside the reviewed
+diff, or that you judge to be a false positive — note the skip rather than
+arguing with it. Finish with a brief summary of what was fixed and what was
+skipped (or confirm the code was already clean).

package/themes/{one-code-light.json → onecode-light.json}

@@ -1,6 +1,6 @@
 {
   "$schema": "https://raw.githubusercontent.com/earendil-works/pi/main/packages/coding-agent/src/modes/interactive/theme/theme-schema.json",
-  "name": "one-code-light",
+  "name": "onecode-light",
   "vars": {
     "clay": "#c05f38",
     "clayDeep": "#9c4a29",
@@ -72,5 +72,10 @@
     "thinkingXhigh": "red",
     "thinkingMax": "violet",
     "bashMode": "amber"
+  },
+  "export": {
+    "pageBg": "#faf7f3",
+    "cardBg": "surface",
+    "infoBg": "surfaceRaised"
   }
 }