refactor(opencode): drop @pm git-ref read mode, no longer used by workflow

@pm originally had two read modes — git-ref (via `git show <ref>:TODO.md`)
and filesystem. Git-ref existed because the workflow once ran in a bare
repo with no working tree. Once the workflow was simplified to assume
opencode is launched in the worktree, every dispatch (Phase 2 read,
Phase 9 update, Failure handler) uses filesystem mode. Git-ref mode
became dead weight: it added bash permissions, an allowlist, a "Bash
Discipline" section, and a dual-mode "How to Read" section, but the
workflow never invoked it. A reviewer correctly flagged the resulting
inconsistency between the two-mode docs and the single-mode usage.

@pm is now single-mode. Bash access is removed (bash: false, no
permission allowlist). The "How to Read" section collapses to "you
operate on TODO/ via the filesystem only" with one explicit pointer
that ad-hoc historical reads (`git show main:TODO/GAL-39.md`) are
out of scope — the user can run that themselves.

The workflow drops the now-redundant "(live filesystem mode)"
qualifier from Phase 2 / Phase 9 / Failure handler dispatches and
the Roles & Dispatch table updates @pm's constraint to "No bash."

config/opencode/agents/pm.md

@@ -7,14 +7,7 @@ tools:
   grep: true
   write: true
   edit: true
-  bash: true
-permission:
-  bash:
-    "*": deny
-    "git show *": allow
-    "git rev-parse *": allow
-    "git ls-tree *": allow
-    "ls *": allow
+  bash: false
 ---
 
 You are a project management assistant. Your sole responsibility is reading and updating files inside a `TODO/` directory. You do **not** modify any file outside that directory under any circumstances.
@@ -34,24 +27,17 @@ TODO/
 - Each issue lives in `TODO/<ID>.md`. IDs are short, stable, and uppercase (e.g. `GAL-1`, `ABC-42`).
 - `TODO/README.md` is a hand-maintained index that groups top-level issues into categories with `[x]`/`[ ]` checkboxes pointing at each issue file.
 
-## How to Read TODO Files
+## How to Read and Write TODO Files
 
-There are two ways, depending on what the caller tells you:
+You operate on the `TODO/` directory through the filesystem only. The caller passes an absolute path to the worktree's `TODO/` directory; resolve issue files as `<TODO_DIR>/<ID>.md`. Use the `read` / `glob` / `grep` tools to inspect, and `write` / `edit` to update.
 
-1. **From a git ref** (no working tree, e.g. inside a bare repo) — run `git show <ref>:TODO/<ID>.md` and parse stdout. List the directory with `git ls-tree --name-only <ref> TODO/`. This mode is **read-only**: never attempt updates. If the caller asks for an update in git-ref mode, refuse and explain that updates require a worktree path.
-2. **From a filesystem path** (caller has a checked-out worktree) — read/edit/write files directly under the supplied absolute `TODO/` path. The caller passes the worktree's `TODO/` directory; resolve issue files as `<TODO_DIR>/<ID>.md`.
-
-The caller indicates the mode in the prompt. When the mode is ambiguous, default to read-only git-ref mode and ask.
-
-If no path or ref is provided, fall back to `./TODO/` relative to the current working directory (ad-hoc invocations only).
+If no path is provided, fall back to `./TODO/` relative to the current working directory (ad-hoc invocations only).
 
 If a required file does not exist when an operation requires it:
-- For read/update: report "Issue file not found at <absolute path or ref>" and stop.
+- For read/update: report "Issue file not found at `<absolute path>`" and stop.
 - For create: see the create rules below.
 
-## Bash Discipline
-
-The only bash commands you may run are `git show <ref>:TODO/<ID>.md`, `git ls-tree …`, `git rev-parse …`, and `ls <TODO_DIR>` (for listing). The permission sandbox enforces this.
+You do **not** have bash access. Historical reads from a git ref (e.g. "what did `GAL-39` look like on `main` last week?") are out of scope — the user can run `git show main:TODO/GAL-39.md` themselves; that's not something this agent needs to wrap.
 
 ## Issue File Schema (`TODO/<ID>.md`)
 
@@ -140,7 +126,7 @@ You cannot:
 - Delete issues. If asked, leave the file in place and report — the new schema has no `Cancelled` state, so deletion would lose history.
 - Modify any file outside `TODO/`.
 - Modify `TODO/README.md` for reasons unrelated to a checkbox sync (no editing the category structure or the intro text without an explicit request).
-- Run shell commands beyond the bash allowlist.
+- Run shell commands. You have no bash access.
 
 ## Output Format
 

config/opencode/commands/workflow.md

@@ -30,7 +30,7 @@ This is a **multi-agent** workflow. There is one orchestrator (you, running in `
 | `@simplify` | Reviews for unnecessary complexity. Advisory recommendations. | Read-only. |
 | `@test` | Writes failing tests for a task spec, verifies RED, hands off to `@make`. | May only modify test files / `#[cfg(test)] mod` blocks. Bash sandboxed to test runners. |
 | `@make` | Implements a single task spec. Verifies acceptance criteria. | May only modify files listed in the task spec. Bash sandboxed to language toolchains; no `git`, network, `cd`. |
-| `@pm` | Reads/updates `TODO/` issue files. | May only modify `TODO/` contents. Bash sandboxed to `git show` / `git ls-tree` / `ls`. |
+| `@pm` | Reads/updates `TODO/` issue files. | May only modify `TODO/` contents. No bash. |
 
 **What "Dispatch" means here.** Every "dispatch `@<name>`" in the phase descriptions is a call to opencode's subagent / task invocation tool with that agent name. Each dispatch starts a **fresh context**: the subagent has no memory of prior phases, no view of this orchestration, and no access beyond what its own file declares. The subagent receives only what the dispatch prompt provides — typically an absolute path to a file in `$RUN_DIR` plus a small per-dispatch context block.
 
@@ -92,7 +92,7 @@ Define `RUN_DIR="$WORKTREE_PATH/.workflow/run-$ISSUE_ID"` once in Phase 1 and re
 
 ## Phase 2: Issue Context
 
-Dispatch `@pm` against `./TODO/` (live filesystem mode; pass the absolute `TODO/` directory path) and fetch the issue at `./TODO/<ID>.md`:
+Dispatch `@pm` against `./TODO/` (pass the absolute `TODO/` directory path) and fetch the issue at `./TODO/<ID>.md`:
 - Title, description, acceptance criteria (if section present)
 - Labels and parent
 - Sub-issues list (if the issue is a parent)
@@ -454,7 +454,7 @@ The workflow is forge-agnostic. It commits locally and stops. **Do not push, and
 - If changes are large/varied, use multiple atomic commits (one per logical unit)
 
 ### TODO Update
-- Dispatch `@pm` against the absolute `./TODO/` path (live filesystem mode). Ask it to:
+- Dispatch `@pm` against the absolute `./TODO/` path. Ask it to:
   - Set the issue file's frontmatter `status` to `Done` (or leave at `In Progress` if the run is incomplete and the user must verify before marking Done).
   - Add a comment of the form: `- YYYY-MM-DD — Branch \`$BRANCH_NAME\`, commit <SHA> — <one-line summary>` (date from the shell, never fabricated).
   - Propagate any status flip to the dependent index: `TODO/README.md` for top-level issues (`parent: null`), or the parent file's `## Sub-issues` line for sub-issues.
@@ -481,7 +481,7 @@ At any phase, if an unrecoverable error occurs:
 1. Write `$RUN_DIR/summary.md` (creating `$RUN_DIR` first if it doesn't exist) with what was completed and what failed. Do **not** stage or commit anything under `.workflow/`.
 2. If any code was written, commit it with message `wip: incomplete workflow run for <issue-id>`. Stage code only — exclude `.workflow/` and `TODO/`.
 3. Leave the branch and worktree intact for the user to inspect — do not push, do not delete.
-4. Dispatch `@pm` against `./TODO/` (live filesystem mode) to add a comment on the issue file (`./TODO/<ID>.md`) summarising what failed.
+4. Dispatch `@pm` against `./TODO/` to add a comment on the issue file (`./TODO/<ID>.md`) summarising what failed.
 5. Stop execution.
 
 **Never hang on interactive prompts.** If any command appears to require input, treat it as a failure and follow the above procedure.