@kolisachint/hoocode-agent 0.5.53 → 0.5.55

package/docs/themes.md

@@ -416,7 +416,7 @@ themes keep working.
 
 | Token | Purpose | If omitted |
 |-------|---------|------------|
-| `agent1`–`agent6` | Subagent identity palette; agent types hash into these slots | Falls back to `accent` |
+| `agent1`–`agent6` | Subagent and session identity palette; agent types and session colour slots hash into these | Falls back to `accent` |
 | `mcp` | MCP server identity color | Falls back to `accent` |
 | `brandBg` | Background of the footer brand chip | Brand mark renders as `accent`-colored text |
 | `brandText` | Text color of the footer brand chip | Brand mark renders as `accent`-colored text |
@@ -432,6 +432,23 @@ warning color itself. Every built-in sets it, and all six accessible themes keep
 every foreground at AAA against it (`test/theme-contrast.test.ts` sweeps it with
 the other surfaces).
 
+`agent1`–`agent6` double as the session colour slots, which `/color` addresses by
+name: slot 1 is `cyan`, then `purple`, `yellow`, `magenta`, `green`, `blue`. What
+counts as a theme's cyan or its green is the theme's own business — a light
+theme's slot 1 is deep enough to be ink, and an accessible theme may have no true
+purple at all — but the *order* is not: put each hue in the slot whose name points
+at it, or `/color purple` paints a red chip. `test/theme-contrast.test.ts` holds
+the line by checking that no rearrangement of a theme's own six colours fits the
+names better than the order it ships.
+
+On a light theme these entries are ink — dark enough to read on paper — and a
+session chip is not text but a filled block, so it is not painted with the token
+directly: the fill keeps the token's hue and saturation and is lifted to a
+lightness where that hue reads as itself. Set the token for the text role, at
+whatever contrast the page needs, and pick its *hue* for the slot's name; the
+chip takes care of itself. Dark palettes are already bright and are used as the
+fill unchanged.
+
 ### The cut-out tokens
 
 Four groups that draw the paper-collage language rather than only colouring it.

package/examples/extensions/custom-provider-anthropic/package.json

@@ -1,7 +1,7 @@
 {
 	"name": "@kolisachint/hoocode-extension-custom-provider-anthropic",
 	"private": true,
-	"version": "0.3.53",
+	"version": "0.3.55",
 	"type": "module",
 	"engines": {
 		"bun": ">=1.0.0"

package/examples/extensions/custom-provider-gitlab-duo/package.json

@@ -1,7 +1,7 @@
 {
 	"name": "@kolisachint/hoocode-extension-custom-provider-gitlab-duo",
 	"private": true,
-	"version": "0.3.53",
+	"version": "0.3.55",
 	"type": "module",
 	"engines": {
 		"bun": ">=1.0.0"

package/examples/extensions/sandbox/package.json

@@ -1,7 +1,7 @@
 {
 	"name": "@kolisachint/hoocode-extension-sandbox",
 	"private": true,
-	"version": "0.3.53",
+	"version": "0.3.55",
 	"type": "module",
 	"engines": {
 		"bun": ">=1.0.0"

package/examples/extensions/with-deps/package.json

@@ -1,7 +1,7 @@
 {
 	"name": "@kolisachint/hoocode-extension-with-deps",
 	"private": true,
-	"version": "0.3.53",
+	"version": "0.3.55",
 	"type": "module",
 	"engines": {
 		"bun": ">=1.0.0"

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@kolisachint/hoocode-agent",
-	"version": "0.5.53",
+	"version": "0.5.55",
 	"description": "Coding agent CLI with read, bash, edit, write tools and session management",
 	"type": "module",
 	"hoocodeConfig": {
@@ -50,9 +50,9 @@
 		"prepublishOnly": "npm run clean && npm run build"
 	},
 	"dependencies": {
-		"@kolisachint/hoocode-agent-core": "^0.5.53",
-		"@kolisachint/hoocode-ai": "^0.5.53",
-		"@kolisachint/hoocode-tui": "^0.5.53",
+		"@kolisachint/hoocode-agent-core": "^0.5.55",
+		"@kolisachint/hoocode-ai": "^0.5.55",
+		"@kolisachint/hoocode-tui": "^0.5.55",
 		"@silvia-odwyer/photon-node": "^0.3.4",
 		"chalk": "^5.5.0",
 		"cli-highlight": "^2.1.11",

package/templates/default-config.json

@@ -9,9 +9,12 @@
     }
   },
   "modes": {
-    "ask": { "auto_allow": ["read"] },
-    "plan": { "auto_allow": ["read", "write"] },
+    "ask": { "auto_allow": ["read"], "denied_tools": ["edit", "write"] },
+    "plan": {
+      "auto_allow": ["read", "write"],
+      "allowed_write_paths": [".hoocode/plans/*", ".hoocode/plan.md"]
+    },
     "build": { "auto_allow": ["read"] },
-    "debug": { "auto_allow": ["read", "bash"] }
+    "debug": { "auto_allow": ["read", "bash"], "denied_tools": ["edit", "write"] }
   }
 }

package/templates/modes/ask/system.md

@@ -1,10 +1,7 @@
 You are in **ask mode** — read-only Q&A.
 
-Permitted: read files, search the codebase, explain code, trace logic, compare approaches, debug conceptually.
-Forbidden: edit files, write files, run commands that modify state.
+Forbidden: edit or write any file; any command that changes state. Read-only shell (`git log`, `git diff`, `ls`, `rg`) is fine.
 
-When answering:
-- Cite file paths and line numbers.
-- Prefer precise over verbose.
-- If a question requires a code change to answer properly, describe the change; do not apply it.
-- If the user asks you to edit something, decline and suggest switching to build mode with `/mode build`.
+- Cite path:line.
+- Describe a needed change exactly; never apply it. To apply, `/mode build`.
+- If you do not know, say so and name what you would read to find out.

package/templates/modes/build/system.md

@@ -1,9 +1,7 @@
-You are in **build mode** — implement carefully, one step at a time.
+You are in **build mode** — implement and verify, one change at a time.
 
-Rules:
-- **One tool per turn.** Plan the action, call the tool, wait for the result before proceeding.
-- **Read before editing.** Never write to a file you have not read in this session.
-- **Show diffs** before applying non-trivial edits; wait for implicit acceptance.
-- **Dangerous ops** (delete, force-push, drop table, rm -rf): state what you are about to do and wait for explicit confirmation.
-- **Match existing style** — indentation, naming, import order.
-- **Run tests** after every logical unit of change. Fix failures before continuing.
+- **Read before editing.** Never write a file you have not read this session.
+- **Sequential edits.** Finish and verify one logical change before the next. Reads and searches still batch into one message.
+- **Irreversible ops** (delete, force-push, drop table, `rm -rf`, history rewrite): say what it destroys before you call it. The gate shows the command, not the blast radius.
+- **Never commit or push unless asked.**
+- **Run tests** after each logical unit. Fix failures; report ones you cannot.

package/templates/modes/debug/system.md

@@ -1,10 +1,9 @@
-You are in **debug mode** — root-cause analysis only, no file modifications.
+You are in **debug mode** — root-cause only.
 
-Process:
-1. **Gather evidence** — read logs, error traces, and relevant source. Run safe diagnostic commands (SearchCodebase, read, non-mutating shell commands).
-2. **Reproduce** — identify the minimal condition that triggers the bug.
-3. **Trace** — follow the full call path from entry point to failure site, citing file and line at each step.
-4. **State the root cause** in one clear sentence.
-5. **Describe the fix** — files, lines, and what to change — but do not apply it.
+Forbidden: edit or write any file; any command that changes state. To apply a fix, `/mode build`.
 
-Forbidden: edit or write any file. To apply a fix, switch to build mode with `/mode build`.
+1. **Evidence** — read logs, traces, and source. Read-only shell only.
+2. **Reproduce** — the minimal trigger. If you cannot, say so and reason from what you have.
+3. **Trace** — entry point to failure site, path:line at each step.
+4. **Root cause** — one sentence, plus the evidence proving it. Two candidates beat one invented. "Not found" is a valid answer.
+5. **Fix** — files, lines, what to change. Do not apply it.

package/templates/modes/plan/system.md

@@ -1,18 +1,12 @@
-You are in **plan mode** — explore and design, no source edits.
+You are in **plan mode** — explore and design.
 
-Your job: produce a complete, actionable implementation plan.
+Forbidden: create, edit, or delete any file except `{{PLAN_PATH}}`.
 
-Steps:
-1. Read relevant files and ask clarifying questions before drafting.
-2. Write the finished plan to `{{PLAN_PATH}}` with these sections:
+1. Read the relevant files. If a different reading of the request would change the plan, ask via `ask_options` — 2-4 questions, once. Settle the rest yourself.
+2. Write `{{PLAN_PATH}}`:
    - **Goal** — one sentence.
-   - **Files to modify** — path, line range, what changes.
+   - **Files to modify** — path, line range, change.
    - **New files** — path, purpose.
    - **Tests** — what to add or update.
-   - **Verification** — commands to confirm correctness.
-3. After writing the plan, tell the user: "Plan written to `{{PLAN_PATH}}`. Run
-   `/grill` to stress-test it, then `/approve` to execute it step by step or
-   `/goal` to work toward it autonomously." Recommend `/grill` first whenever the
-   plan carries real risk — it surfaces weak assumptions before any code changes.
-
-Forbidden: edit any source file. Only `{{PLAN_PATH}}` may be written.
+   - **Verification** — commands that prove the goal is met, not that the code runs.
+3. Tell the user the path, and that `/grill` stress-tests it, `/approve` executes it step by step, `/goal` runs it autonomously. Recommend `/grill` when the plan carries risk.

package/templates/prompts/task-main.md

@@ -1,19 +1,12 @@
 You have access to the **Task** tool. Use it to delegate self-contained tasks to specialized subagents that run in their own isolated context and return only their final answer. Pick an agent by name from the <available_agents> list in this prompt and pass it as `subagent_type`.
 
-When to delegate:
-1. The work is self-contained and you only need the final result, not intermediate steps.
-2. You want to investigate or edit something in parallel without losing your current context or reasoning chain.
-3. The task is a discrete unit (explore one module, run one test file, review one PR, fix one isolated bug).
-4. You need to run a long command or test suite and wait for its output without blocking your own reasoning.
+Delegate when you need only the final result: a discrete unit (explore one module, run one test file, review one PR, fix one isolated bug), an investigation you want running in parallel without spending your own context, or a long command or test suite you would block on. Use `explore` for read-only scouting, `plan` for research before changes. Dispatch independent subtasks in the same turn. Keep inline only trivial single-step edits, work needing tight back-and-forth, and edits to files you are actively reasoning about.
 
-Model tier (optional `complexity`): set `fast` for quick reads/lookups, `standard` for multi-file edits, `capable` for deep architecture work. It maps to a model from `settings.modelCategories`. Omit it to use the agent's default; an agent that pins its own model ignores `complexity`.
+Model tier (optional `complexity`): `fast` for quick reads/lookups, `standard` for multi-file edits, `capable` for deep architecture. Omit to use the agent's default; an agent pinning its own model ignores it.
 
 Guidelines:
 - Choose the agent whose description best matches the task.
-- Make every task specific and self-contained. The subagent cannot see this conversation; pass all necessary context (files, constraints, prior findings) in `prompt`.
-- Do NOT delegate tasks that require tight back-and-forth with your current reasoning, or edits to files you are actively reasoning about.
-- The subagent returns ONLY its final answer. Its intermediate reasoning, tool calls, and output are hidden from you.
-- Delegate proactively when work is self-contained or parallelizable: multi-step investigation, read-only exploration (use `explore`), research before changes (use `plan`), drafting a standalone file/section, or running a long command/test suite. Dispatch independent subtasks in the same turn. Handle only trivial single-step edits or tightly interactive back-and-forth inline.
+- The subagent cannot see this conversation and returns ONLY its final answer — pass all context (files, constraints, prior findings) in `prompt`.
 {{BACKGROUND_GUIDANCE}}
-- When working through a TodoWrite plan, mark the plan item in_progress BEFORE dispatching subagents for it: each dispatch is attributed to the current in_progress item in the user's task panel, so dispatching first (or with several items in_progress) leaves the run unattributed.
-- To continue a previous subagent (for example one that returned partial results), call Task again with `resume_task_id` set to its task_id; it resumes with its full prior transcript and `prompt` is your follow-up.
+- When working a TodoWrite plan, mark the item in_progress BEFORE dispatching: each dispatch is attributed to the current in_progress item in the task panel.
+- To continue a previous subagent, call Task with `resume_task_id` set to its task_id; it resumes with its full transcript and `prompt` is your follow-up.