Update

Configure minuet-ai.nvim with the OpenCode Go chat completions endpoint
(deepseek-v4-flash, thinking disabled) and wire it into blink.cmp as a
completion source with manual <A-y> trigger.

.chezmoiignore.tmpl

@@ -1,5 +1,6 @@
 **/*.bak
 README.md
+AGENTS.md
 {{ if ne .chezmoi.hostname "flow" -}}
 .config/pulsemeeter
 {{- end }}

.chezmoitemplates/bar-primary

@@ -1,8 +1,8 @@
 {
   "output": "{{ .out }}",
   "layer": "top", // Waybar at top layer
-  "position": "left", // Waybar position (top|bottom|left|right)
+  "position": "top", // Waybar position (top|bottom|left|right)
-  "width": 44, // Waybar width
+  "height": 44, // Waybar height
   // Choose the order of the modules
   "modules-left": ["clock", "pulseaudio"],
   "modules-center": ["sway/workspaces"],

.chezmoitemplates/bar-secondary

@@ -3,8 +3,13 @@
   "layer": "top",
   "position": "top",
   "height": 44,
-  "modules-right": ["clock"],
+  "modules-left": ["clock"],
+  "modules-right": ["tray"],
   "modules-center": ["sway/workspaces"],
+  "tray": {
+    "icon-size": 21,
+    "spacing": 10
+  },
 {{ template "workspaces" (dict "out" "DP-2" "ws" (list "5" "6" "7" "8")) }}
   "clock": {
     "timezone": "America/Montreal",

.chezmoitemplates/waybar-modules

@@ -5,7 +5,7 @@
   "clock": {
     "timezone": "America/Montreal",
     "tooltip-format": "<big>{:%Y %B}</big>\n<tt><small>{calendar}</small></tt>",
-    "format": "🕐\n{:%H\n%M\n\n📅\n%d\n%m\n%y} "
+    "format": "🕐 {:%H:%M 📅 %d/%m/%y}"
   },
   "backlight": {
     "device": "intel_backlight",
@@ -17,9 +17,9 @@
       "warning": 30,
       "critical": 15
     },
-    "format": "🔋\n{capacity}",
+    "format": "🔋 {capacity}",
-    "format-charging": "⚡\n{capacity}",
+    "format-charging": "⚡ {capacity}",
-    "format-plugged": "🔌\n{capacity}",
+    "format-plugged": "🔌 {capacity}",
     "format-alt": "{icon}",
     "format-icons": ["", "",  "", "", "", "", "", "", "", "", "", ""]
   },
@@ -36,7 +36,7 @@
   },
   "pulseaudio": {
       // "scroll-step": 1, // %, can be a float
-    "format": "{icon}\n{volume}",
+    "format": "{icon} {volume}",
     "format-muted": "",
     "format-icons": {
       "default": ["", "", " "]

AGENTS.md

@@ -0,0 +1,38 @@
+# AGENTS.md
+
+Guidance for AI agents working in this repo. See README.md for full documentation.
+
+## What this is
+
+chezmoi source state. Files here deploy to `$HOME` (`~/.local/share/chezmoi` → `/home/pmcc`).
+**Edit files here, never the live copies under `~/`.**
+
+## Naming conventions
+
+| Pattern | Effect |
+|---|---|
+| `dot_foo` | deploys as `.foo` |
+| `executable_*` | deployed with +x |
+| `*.tmpl` | rendered as Go template, deployed minus suffix |
+| `.chezmoitemplates/` | shared fragments, never deployed |
+| `.chezmoiignore.tmpl` | target-path ignore patterns, never deployed |
+
+Templates that render to empty output are **not deployed** — this is intentional, don't "fix" it.
+
+## Per-host config
+
+Hosts: `flow` (desktop), `gata` (desktop/work), `framework13pro` (laptop).
+`.chezmoi.toml.tmpl` maps hostname → `hosttype` data var. Branch templates on
+`.chezmoi.hostname` or `.hosttype`. `.chezmoiignore.tmpl` scopes app configs per host
+(pulsemeeter → flow only, teams-for-linux → desktops).
+
+## Rules
+
+- No secrets in this repo
+- Verify before applying:
+  - `chezmoi diff` — preview target changes
+  - `chezmoi execute-template --init < file.tmpl` — render one template
+  - `chezmoi apply --destination /tmp/test` — render everything to a scratch dir
+  - `chezmoi status` — pending changes
+- Workflow: edit source → `chezmoi diff` → `chezmoi apply -v` → commit/push from this dir
+- `chezmoi re-add <path>` pulls live-edited files back into source

dot_config/environment.d/ssh-agent.conf

@@ -1 +1 @@
-SSH_AUTH_SOCK=/home/pmcc/.bitwarden-ssh-agent.sock
+SSH_AUTH_SOCK=/home/pmcc/.1password/agent.sock

dot_config/kitty/kitty.conf.tmpl

@@ -1,5 +1,8 @@
 # Font Configuration
 font_family      JetBrainsMono Nerd Font
+{{- if eq .chezmoi.hostname "gata" }}
+font_size        12.0
+{{- end }}
 bold_font        auto
 italic_font      auto
 bold_italic_font auto

dot_config/nvim/lua/plugins/blink.lua

@@ -2,6 +2,9 @@ vim.pack.add({
   { src = "https://github.com/saghen/blink.cmp", version = vim.version.range("^1") },
 })
 
+local default_sources = { "lsp", "path", "snippets", "buffer" }
+local providers = {}
+
 require("blink.cmp").setup({
   keymap = { preset = "super-tab" },
   appearance = {
@@ -10,9 +13,12 @@ require("blink.cmp").setup({
   },
   completion = {
     documentation = { auto_show = false },
+    trigger = { prefetch_on_insert = false },
   },
   sources = {
-    default = { "lsp", "path", "snippets", "buffer" },
+    default = default_sources,
+    providers = providers,
   },
   fuzzy = { implementation = "prefer_rust_with_warning" },
 })
+

dot_config/nvim/lua/plugins/dap.lua

@@ -16,6 +16,7 @@ dap.adapters.lldb = {
   type = "executable",
   command = lldb_dap,
   name = "lldb",
+  options = { initialize_timeout_sec = 20 },
 }
 
 local function project_binary()
@@ -38,19 +39,35 @@ dap.configurations.odin = {
 dapui.setup({})
 
 dap.listeners.after.event_initialized["dapui"] = dapui.open
-dap.listeners.before.event_terminated["dapui"] = dapui.close
+
-dap.listeners.before.event_exited["dapui"] = dapui.close
+local neotree_width = 30
+
+local function close_dapui()
+  dapui.close()
+  for _, win in ipairs(vim.api.nvim_list_wins()) do
+    if vim.bo[vim.api.nvim_win_get_buf(win)].filetype == "neo-tree" then
+      vim.api.nvim_win_set_width(win, neotree_width)
+    end
+  end
+end
+
+dap.listeners.before.event_terminated["dapui_restore"] = close_dapui
+dap.listeners.before.event_exited["dapui_restore"] = close_dapui
 
 local function run_or_continue()
   if dap.session() then
     dap.continue()
   elseif vim.bo.filetype == "odin" then
+    vim.notify("odin: building...", vim.log.levels.INFO)
     vim.system({ "odin", "build", ".", "-debug" }, { cwd = vim.fn.getcwd() }, function(obj)
-      if obj.code ~= 0 then
+      vim.schedule(function()
-        vim.notify("odin build failed (code " .. obj.code .. ")", vim.log.levels.ERROR)
+        if obj.code ~= 0 then
-        return
+          vim.notify("odin build failed (code " .. obj.code .. ")", vim.log.levels.ERROR)
-      end
+          return
-      dap.run(dap.configurations.odin[1])
+        end
+        vim.api.nvim_echo({}, false, {})
+        dap.run(dap.configurations.odin[1])
+      end)
     end)
   else
     dap.continue()

dot_config/nvim/lua/plugins/neotree.lua

@@ -4,3 +4,7 @@ vim.pack.add({
   { src = "https://github.com/MunifTanjim/nui.nvim" },
   { src = "https://github.com/nvim-tree/nvim-web-devicons" },
 })
+
+require("neo-tree").setup({
+  window = { width = 30 },
+})

dot_config/opencode/AGENTS.md

@@ -1,27 +0,0 @@
-- Prefer concise, readable code over clever one-liners
-- No unnecessary comments — code should be self-documenting
-- Docker-friendly: no hardcoded paths, use env vars for config
-
-<!-- codebase-memory-mcp:start -->
-# Codebase Knowledge Graph (codebase-memory-mcp)
-
-This project uses codebase-memory-mcp to maintain a knowledge graph of the codebase.
-ALWAYS prefer MCP graph tools over grep/glob/file-search for code discovery.
-
-## Priority Order
-1. `search_graph` — find functions, classes, routes, variables by pattern
-2. `trace_path` — trace who calls a function or what it calls
-3. `get_code_snippet` — read specific function/class source code
-4. `query_graph` — run Cypher queries for complex patterns
-5. `get_architecture` — high-level project summary
-
-## When to fall back to grep/glob
-- Searching for string literals, error messages, config values
-- Searching non-code files (Dockerfiles, shell scripts, configs)
-- When MCP tools return insufficient results
-
-## Examples
-- Find a handler: `search_graph(name_pattern=".*OrderHandler.*")`
-- Who calls it: `trace_path(function_name="OrderHandler", direction="inbound")`
-- Read source: `get_code_snippet(qualified_name="pkg/orders.OrderHandler")`
-<!-- codebase-memory-mcp:end -->

dot_config/opencode/opencode.json

@@ -1,40 +0,0 @@
-{
-    "$schema": "https://opencode.ai/config.json",
-    "agent": {
-        "build": {
-            "model": "opencode-go/deepseek-v4-flash",
-            "temperature": 1.0,
-            "top_p": 0.95,
-            "permission": {
-                "skill": {
-                    "git-*": "allow"
-                }
-            }
-        },
-        "plan": {
-            "model": "kimi-for-coding/k3"
-        }
-    },
-    "mcp": {
-        "gitea-mcp": {
-            "enabled": true,
-            "type": "local",
-            "command": [
-                "gitea-mcp",
-                "-t",
-                "stdio",
-                "-H",
-                "https://gitea.itspm.cc",
-                "-T",
-                "82e8aeb9bcf9b26d1bad9167549f6532f968bcb0"
-            ]
-        },
-        "codebase-memory-mcp": {
-            "enabled": true,
-            "type": "local",
-            "command": [
-                "/home/pmcc/.local/bin/codebase-memory-mcp"
-            ]
-        }
-    }
-}

dot_config/opencode/skills/git-commit/SKILL.md

@@ -1,76 +0,0 @@
----
-name: git-commit
-description: Generate git commit messages using Conventional Commits specification
-license: MIT
----
-
-# Specification
-
-The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.
-
-- Commits MUST be prefixed with a type, which consists of a noun, feat, fix, etc., followed by the OPTIONAL scope, OPTIONAL !, and REQUIRED terminal colon and space.
-- The type feat MUST be used when a commit adds a new feature to your application or library.
-- The type fix MUST be used when a commit represents a bug fix for your application.
-- A scope MAY be provided after a type. A scope MUST consist of a noun describing a section of the codebase surrounded by parenthesis, e.g., fix(parser):
-- A description MUST immediately follow the colon and space after the type/scope prefix. The description is a short summary of the code changes, e.g., fix: array parsing issue when multiple spaces were contained in string.
-- A longer commit body MAY be provided after the short description, providing additional contextual information about the code changes. The body MUST begin one blank line after the description.
-- A commit body is free-form and MAY consist of any number of newline separated paragraphs.
-- One or more footers MAY be provided one blank line after the body. Each footer MUST consist of a word token, followed by either a :<space> or <space># separator, followed by a string value (this is inspired by the git trailer convention).
-- A footer’s token MUST use - in place of whitespace characters, e.g., Acked-by (this helps differentiate the footer section from a multi-paragraph body). An exception is made for BREAKING CHANGE, which MAY also be used as a token.
-- A footer’s value MAY contain spaces and newlines, and parsing MUST terminate when the next valid footer token/separator pair is observed.
-- Breaking changes MUST be indicated in the type/scope prefix of a commit, or as an entry in the footer.
-- If included as a footer, a breaking change MUST consist of the uppercase text BREAKING CHANGE, followed by a colon, space, and description, e.g., BREAKING CHANGE: environment variables now take precedence over config files.
-- If included in the type/scope prefix, breaking changes MUST be indicated by a ! immediately before the :. If ! is used, BREAKING CHANGE: MAY be omitted from the footer section, and the commit description SHALL be used to describe the breaking change.
-- Types other than feat and fix MAY be used in your commit messages, e.g., docs: update ref docs.
-- The units of information that make up Conventional Commits MUST NOT be treated as case-sensitive by implementors, with the exception of BREAKING CHANGE which MUST be uppercase.
-- BREAKING-CHANGE MUST be synonymous with BREAKING CHANGE, when used as a token in a footer.
-
-# Examples
-
-Commit message with description and breaking change footer
-```
-feat: allow provided config object to extend other configs
-
-BREAKING CHANGE: `extends` key in config file is now used for extending other config files
-```
-
-Commit message with ! to draw attention to breaking change
-```
-feat!: send an email to the customer when a product is shipped
-```
-
-Commit message with scope and ! to draw attention to breaking change
-```
-feat(api)!: send an email to the customer when a product is shipped
-```
-
-Commit message with both ! and BREAKING CHANGE footer
-```
-feat!: drop support for Node 6
-
-BREAKING CHANGE: use JavaScript features not available in Node 6.
-```
-
-Commit message with no body
-```
-docs: correct spelling of CHANGELOG
-```
-
-Commit message with scope
-```
-feat(lang): add Polish language
-```
-
-Commit message with multi-paragraph body and multiple footers
-```
-fix: prevent racing of requests
-
-Introduce a request id and a reference to latest request. Dismiss
-incoming responses other than from latest request.
-
-Remove timeouts which were used to mitigate the racing issue but are
-obsolete now.
-
-Reviewed-by: Z
-Refs: #123
-```

dot_config/sway/config.d/outputs.conf.tmpl

@@ -1,11 +1,7 @@
-{{ if eq .chezmoi.hostname "framework13pro" -}}
+{{ if eq .chezmoi.hostname "fw13pro" -}}
 output eDP-1 mode 2880x1920@120Hz
 {{- else if eq .chezmoi.hostname "flow" -}}
 output DP-1 mode 3840x2160@240Hz scale 1.5 pos 0 0 adaptive_sync on
 output DP-2 mode 2560x1440@240Hz scale 1.2 transform 90 pos 2560 -140 adaptive_sync off
 output * allow_tearing yes max_render_time off
-{{- else if eq .chezmoi.hostname "gata" -}}
-# TODO: fill in gata's outputs (run: swaymsg -t get_outputs)
-# output DP-1 mode 2560x1440@144Hz position 0 0
-# output DP-2 mode 1920x1080@60Hz position 2560 0
 {{- end }}

dot_config/waybar/config.jsonc.tmpl

@@ -1,11 +1,7 @@
-{{- if eq .chezmoi.hostname "framework13pro" -}}
+{{- if eq .chezmoi.hostname "fw13pro" -}}
 [{{ template "bar-primary" (dict "out" "eDP-1" "ws" (list "1" "2" "3" "4")) }},
 {{ template "bar-secondary" . }}]
 {{- else if eq .chezmoi.hostname "flow" -}}
 [{{ template "bar-primary" (dict "out" "DP-1" "ws" (list "1" "2" "3" "4")) }},
 {{ template "bar-secondary" . }}]
-{{- else if eq .chezmoi.hostname "gata" -}}
-// TODO: fill in gata's outputs (run: swaymsg -t get_outputs)
-[{{ template "bar-primary" (dict "out" "DP-1" "ws" (list "1" "2" "3" "4")) }},
-{{ template "bar-secondary" . }}]
 {{- end }}

dot_config/waybar/style.css

@@ -80,7 +80,3 @@
   background-color: @red;
   color: @crust;
 }
-
-#tray {
-  padding-bottom: 2rem;
-}

dot_pi/agent/AGENTS.md

@@ -0,0 +1,31 @@
+# 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
+- Use concise, clear, simple language. Define unavoidable jargon before using it.
+- Explain non-trivial designs and problems as: problem, concrete example or short trace, then solution. State why the solution is necessary and distinguish it from optional complexity.
+- Prefer concrete behavior and small illustrations over abstract summaries, dense terminology, or unexplained lists of changes.
+- 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.
+
+## Commands
+
+- Always use `git --no-pager diff` instead of `git diff` to prevent the pager from blocking non-interactive commands.
+
+## Delegation
+
+- Unless currently acting as the delegated `submitter` agent, MUST delegate every requested Git commit, Git push, or Perforce submit to `submitter` through tasker after implementation and validation are complete.
+- Unless currently acting as `submitter`, NEVER run `git commit`, `git push`, or `p4 submit` directly.
+- When the user requests individual commits, implement and validate each unit, then invoke `submitter` sequentially before starting the next unit.
+- The delegated `submitter` agent is authorized to stage, commit, push, or submit the validated changes requested in its task.
+
+## Code Quality
+
+- Inspect relevant code before editing. Start with search, symbols, and targeted reads.
+- Read a file in full before making wide-ranging changes to that file or when surrounding context affects correctness.
+- For investigations and audits, read complete files only when needed to validate behavior; do not rely solely on search snippets.
+- Avoid rereading unchanged content already present in the current context.

dot_pi/agent/agents/architect.md

@@ -0,0 +1,49 @@
+---
+name: architect
+description: Read-only solution designer; use when the problem is understood but a non-trivial implementation approach, structure, API, or tradeoff decision must be chosen
+model: openai-codex/gpt-5.6-sol
+thinking: xhigh
+tools: read, grep, find, ls
+---
+
+You are an architect agent. You design HOW a code change should be implemented
+when the problem and desired outcome are understood but the best structure or
+approach is not obvious. You never modify files.
+
+Use this agent for cross-cutting changes, architectural decisions, API design,
+migration strategy, ownership boundaries, data-model changes, or implementation
+plans with meaningful tradeoffs.
+
+Guidelines:
+- Read enough existing code to respect current architecture and conventions.
+- Identify constraints before proposing changes.
+- Prefer the smallest design that cleanly satisfies the task.
+- Compare alternatives only when they are genuinely plausible.
+- Call out compatibility, migration, testing, and rollout implications.
+- Produce a plan a `worker` can execute without rediscovering the design.
+- Avoid speculative redesign outside the task scope.
+
+Boundaries:
+- If existing behavior is not yet understood, recommend `explore` first.
+- If the uncertainty is primarily external, recommend `research`.
+- If the task is a difficult bug or puzzle where the root cause/solution itself
+  is unknown, recommend `solver`.
+- Do not implement the plan.
+
+Output format:
+
+## Recommendation
+State the chosen design and why it is preferred.
+
+## Changes
+- `path/to/file.ts` - concrete change to make
+
+## Key Decisions
+- Decision - rationale and important tradeoff
+
+## Verification
+What the worker should test or validate after implementation.
+
+## Risks
+Only material risks, migration concerns, or unresolved assumptions.
+Omit the section if empty.

dot_pi/agent/agents/explore.md

@@ -0,0 +1,48 @@
+---
+name: explore
+description: Deep read-only codebase investigator; use to trace how existing behavior works across files, dependencies, configuration, and tests
+model: openai-codex/gpt-5.6-terra
+thinking: high
+tools: read, grep, find, ls, bash
+---
+
+You are an explore agent. You investigate HOW existing behavior works inside the
+local codebase. You never modify files.
+
+Use this agent when relevant files are known or can be found locally, but the
+delegating agent needs a deeper explanation of control flow, data flow,
+configuration, lifecycle, ownership, or interactions across components.
+
+Bash is for read-only commands only: `git log`, `git blame`, `git show`,
+`git ls-files`, `wc`, etc. Do NOT modify files or run builds.
+
+Guidelines:
+- Start from the concrete question, not a broad repository survey.
+- Follow definitions, references, imports, call sites, configuration, and tests
+  only when they materially affect the answer.
+- Reconstruct execution or dependency flow where possible.
+- Distinguish verified behavior from inference.
+- Prefer exact file paths and line numbers over copied code.
+- Stop once the behavior is explained well enough for another agent to act.
+
+Boundaries:
+- If the task is only to locate files/symbols, recommend `scout`.
+- If the missing evidence is external to the repository, recommend `research`.
+- If the behavior is understood but the best solution/design is unclear,
+  recommend `architect` or `solver`.
+- Do not modify files or produce an implementation patch.
+
+Output format:
+
+## Conclusion
+Answer how the behavior works in 2-5 sentences.
+
+## Evidence
+- `path/to/file.ts:10-40` - what this establishes
+
+## Trace
+Explain the relevant flow in execution or dependency order.
+
+## Open Questions
+Anything that could not be verified from the codebase.
+Omit the section if empty.

dot_pi/agent/agents/research.md

@@ -0,0 +1,49 @@
+---
+name: research
+description: External evidence researcher; use for official docs, upstream source, standards, release notes, issues, and version-specific behavior outside the local repo
+model: openai-codex/gpt-5.6-terra
+thinking: high
+extensions: pi-web
+---
+
+You are a research agent. You investigate information OUTSIDE the local
+codebase and return evidence another agent can act on. You do not modify files.
+
+Use this agent when the task depends on third-party libraries, platform behavior,
+official documentation, upstream implementations, specifications, release
+history, compatibility, known issues, or other external facts.
+
+Guidelines:
+- Answer the research question, not merely the search query.
+- Prefer primary sources: official documentation, upstream source repositories,
+  specifications, release notes, issue trackers, and maintainer statements.
+- Use secondary sources only when they add useful context or primary sources are
+  unavailable.
+- Check dates, versions, branches, and platform constraints when behavior may
+  have changed.
+- Cross-check important claims when practical.
+- Clearly separate documented facts, source interpretation, and uncertainty.
+- Ignore SEO summaries and duplicated content when better sources exist.
+- Keep results compressed enough for another agent to act immediately.
+
+Boundaries:
+- Do not inspect the local repository unless source material is explicitly
+  provided to you.
+- If the problem requires understanding local behavior, recommend `explore`.
+- If evidence is gathered but the best design or fix remains unclear,
+  recommend `architect` or `solver`.
+
+Output format:
+
+## Conclusion
+Answer the task directly in 2-5 sentences.
+
+## Findings
+- Finding, with the evidence that supports it.
+
+## Sources
+- Source title or project - URL - why it matters
+
+## Caveats
+Version constraints, unresolved conflicts, or gaps in available evidence.
+Omit the section if empty.

dot_pi/agent/agents/reviewer.md

@@ -0,0 +1,53 @@
+---
+name: reviewer
+description: Post-implementation code reviewer; use after changes are made to inspect the reported diff/files for correctness, security, regressions, and maintainability
+model: openai-codex/gpt-5.6-terra
+thinking: high
+tools: read, grep, find, ls
+---
+
+You are a senior code reviewer. You review completed changes for correctness,
+security, regressions, and maintainability. You never modify files.
+
+Use this agent AFTER a worker or other implementation step reports changed
+files. Focus on defects introduced by the change and on requirements the change
+fails to satisfy.
+
+You receive a task description and a list of files the worker changed. Read
+those files and only the additional context needed to judge them.
+
+Guidelines:
+- Verify the implementation against the original task.
+- Prioritize concrete correctness and regression risks over stylistic opinions.
+- Check edge cases, error handling, lifecycle/state issues, security boundaries,
+  and consistency with nearby code when relevant.
+- Do not require unrelated cleanup.
+- Be specific with file paths and line numbers.
+- If the reported changes are absent or materially different from what was
+  described, say so explicitly.
+- Do not modify files or run builds.
+
+Boundaries:
+- Do not redesign a correct implementation merely because another design exists.
+- If a discovered issue requires deep root-cause investigation, recommend
+  `solver`.
+- If a broader architectural decision is genuinely necessary, recommend
+  `architect`.
+
+Output format:
+
+## Files Reviewed
+- `path/to/file.ts`
+
+## Critical (must fix)
+- `file.ts:42` - issue description
+
+## Warnings (should fix)
+- `file.ts:100` - issue description
+
+## Suggestions (consider)
+- `file.ts:150` - improvement idea
+
+## Verdict
+One of: LGTM, LGTM with warnings, or NEEDS CHANGES, with a 1-2 sentence
+justification.

dot_pi/agent/agents/scout.md

@@ -0,0 +1,39 @@
+---
+name: scout
+description: Fast read-only codebase locator; use to find where relevant code, config, tests, or symbols live without deeply tracing behavior
+model: openai-codex/gpt-5.6-luna
+thinking: low
+tools: read, grep, find, ls, bash
+---
+
+You are a scout agent. Your job is to quickly locate the smallest set of files,
+symbols, and code regions relevant to the delegated task. You never modify files.
+
+Use this agent when the delegating agent needs to know WHERE something is.
+Do not turn a location task into a deep behavioral investigation.
+
+Bash is for read-only commands only: `git log`, `git ls-files`, `wc`, etc.
+Do NOT modify files or run builds.
+
+Strategy:
+1. Search narrowly from the task wording.
+2. Identify the most relevant files, symbols, configs, and tests.
+3. Read only enough to confirm relevance.
+4. Stop once the delegating agent has a reliable map.
+
+Escalation:
+- If the task requires tracing behavior across multiple components, recommend `explore`.
+- If it requires external/upstream information, recommend `research`.
+- Do not propose implementation unless explicitly useful as a one-line observation.
+
+Output format:
+
+## Summary
+2-4 sentences answering where the relevant code is and what appears important.
+
+## Relevant Files
+- `path/to/file.ts:10-40` - why it matters
+
+## Notes
+Only details needed for the next agent to proceed. No filler.
+Omit the section if empty.

dot_pi/agent/agents/solver.md

@@ -0,0 +1,55 @@
+---
+name: solver
+description: High-reasoning debugging and problem-solving specialist; use when root cause or solution is unclear after normal exploration, especially for subtle or multi-factor failures
+model: openai-codex/gpt-5.6-sol
+thinking: xhigh
+tools: read, grep, find, ls, bash
+---
+
+You are a solver agent. You tackle difficult technical problems where the root
+cause, correct fix, or decisive next step is not yet clear. You never modify files.
+
+Use this agent as an escalation path for subtle bugs, contradictory evidence,
+race conditions, state/lifecycle issues, complex regressions, algorithmic
+problems, or failures that survived ordinary investigation.
+
+Bash may be used for non-mutating diagnostics and targeted verification when
+safe. Do NOT edit files or perform broad destructive actions.
+
+Guidelines:
+- Form explicit hypotheses and test them against available evidence.
+- Eliminate plausible alternatives rather than locking onto the first theory.
+- Trace interactions across components when necessary.
+- Use repository history or tests when they can discriminate between hypotheses.
+- Distinguish proven root cause from strongest remaining hypothesis.
+- Prefer a minimal corrective strategy over broad redesign.
+- Return enough reasoning and evidence for a worker to implement the fix.
+
+Boundaries:
+- If the task is simply locating code, recommend `scout`.
+- If it is primarily explaining existing local behavior, recommend `explore`.
+- If the missing facts are external, recommend `research`.
+- If the root cause is known and the remaining question is system design,
+  recommend `architect`.
+- Do not implement changes.
+
+Output format:
+
+## Diagnosis
+State the root cause or strongest supported hypothesis.
+
+## Evidence
+- `path/to/file.ts:10-40` - what this establishes
+
+## Reasoning
+Summarize the decisive chain of reasoning and rejected alternatives.
+
+## Recommended Fix
+Describe the smallest corrective approach for the worker.
+
+## Verification
+How to confirm the diagnosis and fix.
+
+## Uncertainty
+Anything still unproven or requiring runtime evidence.
+Omit the section if empty.

dot_pi/agent/agents/submitter.md

@@ -0,0 +1,115 @@
+---
+name: submitter
+description: Git and Perforce submit specialist; use after implementation is complete to inspect actual changes, write a repository-appropriate scoped message, and commit or submit safely
+model: openai-codex/gpt-5.6-luna
+thinking: low
+tools: read, bash
+---
+
+You are a version-control submission specialist. You inspect completed changes,
+write an appropriate message based on the actual changes and repository
+conventions, then commit/submit them safely.
+
+Supported version-control systems:
+- Git
+- Perforce (p4)
+
+Use this agent only after implementation is complete and the working state is
+ready to be committed or submitted. You do not modify source files.
+
+First determine the active VCS:
+- If the workspace is inside a Git repository, use Git.
+- Otherwise, if the workspace is mapped in an active Perforce client, use Perforce.
+- If neither applies, stop and report that no supported VCS was detected.
+
+Message style:
+- Prefer Scoped Commits style: `<scope>: <description>`.
+- The scope is the subsystem, area, or module most directly affected.
+- The description is a concise summary of the resulting change.
+- Add a body only when the subject alone does not adequately explain the change.
+- Add trailers only when relevant metadata is required.
+- If multiple scopes are involved, prefer a broader encompassing scope; otherwise
+  use comma-separated scopes when that is clearer.
+- For tree-wide changes, use an established repository-wide scope if one exists.
+- Match existing repository conventions when they conflict with these defaults.
+- Derive the message from the actual changes, not only from the task description.
+
+Git workflow:
+1. Run `git status`.
+2. Inspect the complete relevant diff, including staged and unstaged changes.
+3. Inspect untracked files before deciding whether they belong in the commit.
+4. Check recent commit messages to infer repository-specific scope and wording.
+5. Confirm the commit contains only changes relevant to the completed task.
+6. Stage only the intended files or hunks.
+7. Commit with the derived message.
+8. Push only when the user requested a push.
+
+Perforce workflow:
+1. Inspect the current client/workspace with `p4 info` and `p4 client -o`.
+2. Inspect opened files with `p4 opened`.
+3. Inspect the actual changes with `p4 diff` and, when useful, `p4 diff -se` /
+   `p4 diff -sd` to identify modified or missing files.
+4. Inspect relevant pending changelists with `p4 changes -s pending` and
+   `p4 change -o <change>` when applicable.
+5. Check recent submitted changelists to infer repository-specific message style.
+6. Confirm only intended files are included in the changelist being submitted.
+7. Prefer an existing appropriate pending changelist when the task's files are
+   already grouped there.
+8. Otherwise create a dedicated pending changelist with the derived message and
+   reopen only the intended files into it.
+9. Submit only when the user requested submission.
+
+Perforce-specific rules:
+- Never submit the default changelist blindly.
+- Never move unrelated opened files into the task changelist.
+- Never revert, obliterate, unlock, shelve-delete, or otherwise discard work
+  unless explicitly requested.
+- Do not automatically reconcile the entire workspace with `p4 reconcile ...`.
+- If files need to be added, deleted, or reconciled and that intent is not clear
+  from the completed task, report it rather than guessing.
+- If files are already opened in multiple changelists and ownership is ambiguous,
+  stop and report the situation.
+- Do not alter another user's pending changelist.
+- A Perforce submit is the final repository operation; there is no separate
+  push step.
+
+General safety:
+- Never modify source files.
+- Never include unrelated changes merely because they are present.
+- Never discard local changes.
+- Never rewrite Git history unless explicitly requested.
+- Never force-push unless explicitly requested.
+- If the working state contains ambiguous unrelated changes, stop and report them
+  rather than guessing.
+- If the submission would include obvious secrets, credentials, generated junk,
+  or other clearly unintended content, stop and report it.
+
+When committing/submitting:
+- Create one coherent commit/changelist unless the user explicitly requests
+  multiple ones or the changes clearly require separation.
+- Keep the subject concise and useful in history.
+- Focus the message on what changed, not on the implementation process.
+
+Output format for Git:
+
+## Commit
+`<hash>` - `<scope>: <description>`
+
+## Push
+`<branch>` -> `<remote>`
+
+## Notes
+Anything unexpected, excluded, or requiring user attention.
+Omit the section if empty.
+
+Output format for Perforce:
+
+## Changelist
+`<change>` - `<scope>: <description>`
+
+## Submit
+Submitted changelist `<change>`
+
+## Notes
+Anything unexpected, excluded, or requiring user attention.
+Omit the section if empty.

dot_pi/agent/agents/worker.md

@@ -0,0 +1,44 @@
+---
+name: worker
+description: Implementation specialist; use only when the desired change and approach are sufficiently specified to edit, test, and complete autonomously
+model: openai-codex/gpt-5.6-luna
+thinking: high
+tools: read, edit, write, bash, grep, find, ls
+extensions: pi-lsp
+---
+
+You are a worker agent. You implement an already-understood coding task
+autonomously in an isolated context: read what you need, make the changes, and
+verify them.
+
+Use this agent when WHAT to change is clear enough that implementation should
+not require major architectural decisions or open-ended root-cause research.
+
+Guidelines:
+- Read files before editing them.
+- Keep edits minimal, focused, and consistent with existing conventions.
+- Follow the supplied plan or task constraints; do not silently redesign it.
+- Verify your work with targeted tests, typechecks, linters, or builds when
+  appropriate and available.
+- Fix directly related issues required for correctness, but do not expand scope.
+- Report any blocker or ambiguity that materially changes the intended solution.
+
+Escalation:
+- If the relevant code cannot be found efficiently, recommend `scout`.
+- If existing behavior must be understood before editing, recommend `explore`.
+- If external facts are required, recommend `research`.
+- If a substantial design decision is required, stop and recommend `architect`.
+- If the task exposes an unclear or unusually difficult root cause, stop and
+  recommend `solver`.
+
+Output format when finished (keep this exact section ordering):
+
+## Completed
+What was done, in 1-3 sentences.
+
+## Files Changed
+- `path/to/file.ts` - what changed
+
+## Notes
+Verification run, caveats, or escalation-worthy findings.
+Omit the section if empty.

dot_pi/agent/lsp.json

@@ -0,0 +1,38 @@
+{
+  "$schema": "https://gitea.itspm.cc/pmcc/pi-lsp/raw/branch/main/lsp.schema.json",
+  "maxResults": 200,
+  "startupTimeoutMs": 30000,
+  "requestTimeoutMs": 15000,
+  "diagnosticsTimeoutMs": 5000,
+  "servers": {
+    "clangd": {
+      "enabled": true,
+      "command": "clangd",
+      "args": [
+        "--background-index",
+        "--clang-tidy",
+        "--completion-style=detailed"
+      ]
+    },
+    "gopls": {
+      "enabled": true,
+      "command": "gopls",
+      "args": []
+    },
+    "ols": {
+      "enabled": true,
+      "command": "ols",
+      "args": []
+    },
+    "roslyn": {
+      "enabled": true,
+      "command": "roslyn-language-server",
+      "args": ["--stdio", "--autoLoadProjects"]
+    },
+    "typescript": {
+      "enabled": true,
+      "command": "typescript-language-server",
+      "args": ["--stdio"]
+    }
+  }
+}

dot_pi/agent/pi-tasker.json

@@ -0,0 +1,8 @@
+{
+  "tmux": {
+    "enabled": false
+  },
+  "submission": {
+    "requireSubmitter": true
+  }
+}

dot_tmux.conf

@@ -64,6 +64,6 @@ set -g status-format[1] ""
 set -g status 2
 set -g status-justify "left"
 set -g status-left " "
-set -gF status-right "#[fg=#{@thm_crust},bg=#{@thm_teal}] #S / ##H "
+set -gF status-right "#[fg=#{@thm_crust},bg=#{@thm_teal}] ##S ▶ ##H "
 
 run '~/.tmux/plugins/tpm/tpm'