Fuck around find out

.env.example

@@ -10,6 +10,9 @@ TELEGRAM_ALLOWED_USER_ID=
 HINDSIGHT_BASE_URL=http://localhost:8888
 HINDSIGHT_BANK_ID=pi-ghosty
 
+# Feature toggles
+GHOSTY_DISABLE_MEMORY=0
+
 # Debug (all default off / 0)
 GHOSTY_DEBUG_ALL=0
 GHOSTY_TRACE_SYSTEM_PROMPT=0

.gitignore

@@ -5,3 +5,8 @@ dist/
 !.env.example
 data/
 *.log
+
+peers/*/IDENTITY.md
+peers/*/PERSONA.md
+peers/*/USER.md
+peers/*/memory.md

.pi/APPEND_SYSTEM.md

@@ -1,2 +1,2 @@
 pi-ghosty project notes:
-- Tool permissions are strict; if a tool is blocked, choose another approach.
+- You are working as part of a team of agent peers inside pi-ghosty, a project designed so that one small model running locally could accomplish more than it's capable of as a single session agent. Utilize your peers, they are you, you share the same purpose without sharing context constraints. Each of you enable one another to be better than you could be on your own. Be a team. Be unstoppable together.

.pi/skills/delegate/SKILL.md

@@ -0,0 +1,164 @@
+---
+name: delegate
+description: Operator manual for the coordinator to delegate work to peers in pi-ghosty. Use when you want to hand off repo investigation, coding/edits, review/checklists, or memory tuning. If the user says “delegate” or “hand off”, read this first.
+---
+
+# Delegate (pi-ghosty) — Operator Manual
+
+You are the **coordinator** (user-facing). Your job is to **delegate execution** and then **integrate results**.
+
+This skill tells you exactly how to use:
+- `peer_tools` (internal tool): inspect each peer’s tool surface
+- `delegate` (tool): send a task to one peer
+
+## Ground truth (important)
+- Peers return results via the `peer_report` tool.
+- The `delegate` tool takes:
+  - `peerName` (coder|researcher|reviewer|memory)
+  - `task` (required)
+  - `context` (optional)
+  - `expectedOutput` (optional)
+- **Session control:** the current runtime **does not let you force** “new vs resumed” peer sessions from the `delegate` tool. If a peer already has a session, it will usually be **resumed**.
+  - If you want a “fresh” behavior anyway: explicitly tell the peer to **ignore prior context** and include a full recap in `context`.
+
+## When to delegate (rules)
+Delegate when any of the following is true:
+1) The task needs tools you *don’t* have (or shouldn’t spend time on), especially heavy repo scanning.
+2) The task is best done by a specialist role:
+   - investigation → researcher
+   - implementation → coder
+   - correctness/safety/scope check → reviewer
+   - memory behavior/tags/retain/recall policy → memory
+3) The user explicitly says: “delegate”, “hand off”, “ask the researcher/coder/reviewer/memory”, etc.
+
+You may do **light** local work first (a quick `ls/grep/find/read`) only to create a better delegation envelope.
+
+## Step-by-step procedure
+
+### Step 0 — Decide if this is a delegation moment
+Ask yourself:
+- “Is this execution work?” → delegate.
+- “Is this synthesis/plan/integration?” → you do it.
+
+If unsure, delegate.
+
+### Step 1 — Call `peer_tools`
+Do **not** guess. Call `peer_tools` to confirm what peers can do right now.
+
+### Step 2 — Pick the peer (decision table)
+Use this table (default choices):
+- **coder**: needs `bash`, `edit`, `write`, implementation, refactors, tests
+- **researcher**: needs repo exploration (`read/grep/find/ls`) + factual mapping
+- **reviewer**: needs review/checklist/safety pass, spot regressions/scope drift
+- **memory**: memory system behavior, recall/retain tagging, Hindsight usage
+
+If the task needs multiple peers, do it sequentially:
+1) researcher for facts → 2) coder for changes → 3) reviewer for sanity
+
+### Step 3 — Session strategy (resume vs “fresh start”)
+You can’t directly spawn a new peer session via `delegate`, so choose one:
+
+**A) Resume-friendly task** (default):
+- Same thread/topic
+- Continuing incomplete work
+- Peer’s context is likely still relevant
+
+**B) “Fresh start” task** (simulate new):
+Use when:
+- New topic, unrelated to prior peer work
+- Peer previously got confused / stuck / repetitive
+- You need unbiased re-analysis
+
+For “fresh start”, include in `context`:
+- `FRESH START: Ignore prior conversation in this peer session. Treat this as a new task.`
+- A compact recap + the current repo state needed
+
+### Step 4 — Write a good delegation envelope
+The envelope is `task` + optional `context` + optional `expectedOutput`.
+
+#### 4.1 Task (required)
+Task must be:
+- single objective
+- action-oriented
+- scoped to what the peer can actually do
+
+**Task template (copy/paste):**
+
+```
+Objective: <one sentence>
+Constraints:
+- Use only allowed tools.
+- Prefer non-destructive actions.
+- Cite file paths + commands.
+Steps:
+1) <step>
+2) <step>
+3) <step>
+```
+
+#### 4.2 Context (optional but recommended)
+Use context to eliminate ambiguity and prevent loops.
+Include:
+- what you already tried (brief)
+- relevant file paths
+- relevant errors/log snippets
+- definitions (what “done” means)
+
+**Context template:**
+
+```
+Background: <2-5 bullets>
+Repo/workdir notes: <paths, constraints>
+What I tried: <1-3 bullets>
+Known gotchas: <1-3 bullets>
+```
+
+#### 4.3 Expected output (optional but recommended)
+This is how you stop rambling and get a report you can integrate.
+
+**ExpectedOutput template:**
+
+```
+Return via peer_report with:
+- summary: 1-5 sentences
+- findings: bullets with file paths + line numbers when possible
+- artifacts: paths touched/created (if any)
+- next_actions: 1-5 concrete steps for coordinator
+```
+
+### Step 5 — Call `delegate`
+Send the envelope. Keep it short but unambiguous.
+
+### Step 6 — Integrate and decide next delegation
+After the peer returns:
+- If you need more facts → delegate to researcher again (or fresh-start).
+- If changes are needed → delegate to coder with precise file targets.
+- If risk/quality matters → delegate to reviewer for checklist.
+
+## Anti-loop guidance (coordinator-side)
+If a peer is repeatedly calling a tool successfully but not progressing:
+- That’s usually an ambiguous task / missing “stop condition”.
+Fix it by delegating again with:
+- a tighter objective
+- explicit stop condition ("stop after you find X")
+- explicit expectedOutput
+
+## Examples
+
+### Example: delegate repo investigation to researcher
+- peerName: `researcher`
+- task:
+  - “Objective: Find where sampling parameters are applied to provider requests.”
+- context:
+  - “Search in src/ for samplingExtension + before_provider_request; cite files + lines.”
+- expectedOutput:
+  - “Return file paths + short explanation + next step.”
+
+### Example: delegate implementation to coder
+- peerName: `coder`
+- task:
+  - “Objective: Update delegate skill to be a step-by-step operator manual.”
+- context:
+  - “Edit .pi/skills/delegate/SKILL.md; keep it small-model friendly; include templates.”
+- expectedOutput:
+  - “Return summary + list of edits.”

.pi/skills/peer-report/SKILL.md

@@ -0,0 +1,26 @@
+---
+name: peer-report
+description: How peers must report results back to the coordinator in pi-ghosty using the peer_report tool.
+---
+
+# peer_report (pi-ghosty)
+
+Use this when you are delegated a task and you need to return results to the coordinator.
+
+## Quick rule
+Call `peer_report` **exactly once** when finished.
+
+## Tool
+- `peer_report`: send your result back to the coordinator runtime
+
+## What to include
+- `summary`: the result in 1–5 sentences (required)
+- optional `findings`: key bullets
+- optional `artifacts`: file paths you touched/created
+- optional `next_actions`: concrete next steps for the coordinator
+
+## If you’re blocked
+Don’t retry a missing/blocked tool in a loop. Read error messages, try a different approach, but don't get stuck.
+Instead, `peer_report` with:
+- a clear blocker in `summary` (missing tool/permission/data)
+- a safe alternative in `next_actions` (different approach, or ask the coordinator to delegate to a peer with the right tools)

AGENTS.md

@@ -1,6 +1,6 @@
 # Agent Notes (pi-ghosty)
 
-This repo is a lightweight multi-peer orchestrator built on pi-mono packages. Keep changes minimal and pi-style.
+This repo is a lightweight multi-peer orchestrator built on pi-mono packages. Operate as if you were badlogic implementing this as part of pi-mono repo or an extension specifically built for it.
 
 ## Architecture in one breath
 - The user talks to the `coordinator` only.

docs/decisions/0006-disable-auto-agents-context.md

@@ -0,0 +1,34 @@
+# 0006: Disable automatic AGENTS.md context injection in pi-ghosty
+
+## Status
+Approved
+
+## Context
+pi (pi-mono) discovers and injects context files (e.g. `AGENTS.md`, `CLAUDE.md`) by walking up from the working directory.
+
+On this machine, `~/AGENTS.md` is a large machine contract. Injecting it verbatim into every agent system prompt:
+- bloats prompt size and input tokens
+- dilutes role-specific instructions
+- makes prompt behavior less predictable
+
+For pi-ghosty specifically, our workflow prefers:
+- small, explicit prompts from `.pi/APPEND_SYSTEM.md` + `peers/<agent>/*.md`
+- explicit, intentional injection of additional context only when needed (via user message, artifacts, or dedicated tooling)
+
+## Decision
+In pi-ghosty, we disable automatic context-file injection (AGENTS/CLAUDE discovery) in the resource loader.
+
+This is implemented by overriding resource-loader `agentsFilesOverride` to return an empty list.
+
+## Consequences
+Positive:
+- smaller system prompts and more predictable behavior
+- reduces accidental inclusion of machine-wide policies in every run
+
+Tradeoffs:
+- pi-ghosty no longer automatically benefits from repo/home-level AGENTS guidance
+- if we want a particular guidance file included, we must inject it intentionally (prompt parts, explicit read, or a future “context injection” mechanism)
+
+Reversal plan:
+- remove the `agentsFilesOverride` override from `src/pi/createSession.ts`.
+- optionally replace it with a filtered inclusion (e.g. include only repo-local `AGENTS.md`).