task-agent 0.1.342__tar.gz → 0.1.490__tar.gz

task_agent-0.1.490/.env

@@ -0,0 +1,3 @@
+TA_EJECT_TASKS=true
+TA_EJECTED_TASKS_PATH=/home/mstouffer/repos/task-agent/.task-agent/tasks
+TA_EJECTED_ISSUES_PATH=/home/mstouffer/repos/task-agent/.task-agent/tasks

task_agent-0.1.490/.ta/agents/agy-cli/meta.toml

@@ -0,0 +1,12 @@
+name = "agy-cli"
+description = "AGY CLI agent workflow template running agy, claude, or opencode non-interactively"
+
+[dotfiles]
+".gitconfig" = { source = "inline", content = """
+[user]
+    name = Agent
+    email = agent@localhost
+[safe]
+    directory = *
+""" }
+".ssh/id_ed25519" = { source = "generate" }

task_agent-0.1.490/.task-agent/tasks/.task-agent/datapackage.json

@@ -0,0 +1,27 @@
+{
+  "name": "mission-control",
+  "resources": [
+    {
+      "name": "mission",
+      "path": "mission.usv",
+      "format": "csv",
+      "delimiter": "\u001f",
+      "schema": {
+        "fields": [
+          {
+            "name": "name",
+            "type": "string"
+          },
+          {
+            "name": "slug",
+            "type": "string"
+          },
+          {
+            "name": "dependencies",
+            "type": "string"
+          }
+        ]
+      }
+    }
+  ]
+}

task_agent-0.1.490/.task-agent/tasks/.task-agent/logs/2026-06-10.jsonl

@@ -0,0 +1 @@
+{"detail": {"branch": "issue/allow-dots-in-task-slugs-for-numeric-hierarchies", "path": ".gwt/allow-dots-in-task-slugs-for-numeric-hierarchies"}, "e": "worktree.created", "slug": "allow-dots-in-task-slugs-for-numeric-hierarchies", "t": "2026-06-10T17:58:38.341215+00:00", "user": ""}

task_agent-0.1.490/.task-agent/tasks/.task-agent/logs/2026-06-11.jsonl

@@ -0,0 +1,2 @@
+{"detail": {"reason": "done"}, "e": "worktree.removed", "slug": "allow-dots", "t": "2026-06-11T16:12:42.585718+00:00", "user": ""}
+{"detail": {"reason": "done"}, "e": "worktree.removed", "slug": "allow-dots", "t": "2026-06-11T16:13:07.351186+00:00", "user": ""}

task_agent-0.1.490/.task-agent/tasks/.task-agent/mission.usv

@@ -0,0 +1,12 @@
+Investigate better integration with Antigravity CLI of Claude CLIinvestigate-better-integration-with-antigravity-cli-of-claude-cli
+Auto-clean .code_signatures.json after no-verify commitsauto-clean-code-signaturesjson-after-no-verify-commits
+Remove dependency on GH CLI by adding APIremove-dependency-on-gh-cli-by-adding-api
+Allow create task in other repoallow-create-task-in-other-repo
+Add secondary documents to the task viewadd-secondary-documents-to-the-task-view
+shard-completed-tasks-by-month-and-index-historyshard-completed-tasks-by-month-and-index-history
+Create decompose feature to decompose a taskcreate-decompose-feature-to-decompose-a-task
+Test Issuetest-issue
+New Tasknew-tasktest-issue
+Add Dependency model with required reason for dependency declarationsadd-dependency-model-with-required-reason-for-dependency-declarations
+pyproject.toml (sketch)slug-identified-tasks-with-symlinked-state-folders
+Test Interactive Tasktest-interactive-task## Description

task_agent-0.1.490/.task-agent/tasks/active/investigate-better-integration-with-antigravity-cli-of-claude-cli/README.md

@@ -0,0 +1,11 @@
+---
+created_at: 2026-06-18T22:01:50.644632-07:00
+---
+
+# Investigate better integration with Antigravity CLI of Claude CLI
+
+Can we improve integration with agent CLIs?
+
+agy has Gems and other tools integrations. Is there a tool model or interface that would give us even better integration with these CLIs, like maybe that would display status in the CLI interface or something like that?
+
+Is there any way for us to encourage the tools to use task-agent as their default task manager? It is already working well, but should we be doing anything to make it even more integrated? Maybe by using the inter-agent protocol, or by using a locally running small version of Gemma to prioritize tasks and select the next task?

task_agent-0.1.490/.task-agent/tasks/active/investigate-better-integration-with-antigravity-cli-of-claude-cli/investigation_integration.md

@@ -0,0 +1,78 @@
+# Investigation: Enhancing Task Agent Integration with Agent CLIs
+
+This report investigates improvements to the integration between **Task Agent** (`ta`) and developer agent CLIs such as **Antigravity CLI** (`agy`), **Claude Code** (`claude`), and **OpenCode** (`opencode`).
+
+---
+
+## 1. Overview of the Integration Architecture
+
+Task Agent acts as a structured, prioritized task database (`mission.usv`). Developer CLIs interface with it using the **Model Context Protocol (MCP)**, granting LLMs tool-level access to query, update, and complete tasks.
+
+```mermaid
+graph TD
+    subgraph CLIs ["Agent CLIs"]
+        agy["Antigravity CLI (agy)"]
+        claude["Claude Code"]
+        opencode["OpenCode"]
+    end
+
+    subgraph MCP ["Task Agent MCP Server"]
+        fastmcp["FastMCP Router"]
+        core["TaskAgent Core API"]
+        db[("mission.usv (Task DB)")]
+    end
+
+    subgraph AI ["AI Prioritizer (Proposed)"]
+        gemma["Local Gemma 2B/9B (Ollama)"]
+    end
+
+    CLIs -- "Model Context Protocol" --> fastmcp
+    fastmcp --> core
+    core --> db
+    gemma -- "Analyze & Prioritize" --> db
+```
+
+---
+
+## 2. Key Areas for Improvement & Proposals
+
+### 💡 Proposal A: Shell Prompt Integration (`ta-prompt`)
+Currently, developers must manually run `ta active` or `ta list` to see what task is active.
+*   **Concept**: Implement a shell integration (similar to git prompt builders like Starship) that displays the currently active task slug and priority directly in the terminal prompt.
+*   **Implementation**: Add a lightweight command:
+    ```bash
+    ta prompt
+    # Outputs: [ta:create-agy-cli (p1)]
+    ```
+    This can be sourced in `.bashrc` / `.zshrc` to keep the active task always visible to the developer.
+
+### 🔌 Proposal B: Auto-configure Antigravity CLI (`agy`)
+We already support auto-registering the task-agent MCP server with `claude` and `opencode` via `ta init-mcp`.
+*   **Concept**: Add support for registering with `agy`.
+*   **Implementation**: Extend `ta init-mcp` to support the `--agy` flag, which adds the task-agent MCP server configuration to `~/.gemini/antigravity-cli/mcp_config.json` automatically:
+    ```bash
+    ta init-mcp --agy
+    ```
+
+### 🧠 Proposal C: Local Gemma-based Task Prioritization
+Instead of manual priority adjustments, we can utilize a small, locally-running LLM (like Gemma 2B or 9B via Ollama) to prioritize the queue.
+*   **Concept**: Run a local Gemma model to analyze the dependencies, description complexity, and codebase context to auto-sort tasks.
+*   **Implementation Flow**:
+    1. Read all tasks from `mission.usv` (including titles, descriptions, and criteria).
+    2. Extract file references and recent commit histories to build context.
+    3. Call the local Gemma model (via `http://localhost:11434/api/generate`) with a structured prompt asking it to order the tasks by dependency and logical progression.
+    4. Write back the optimized ordering to `mission.usv`.
+
+### 🤝 Proposal D: Inter-Agent Protocol (IAP) Coordination
+For workspaces where multiple agents are running in parallel:
+*   **Concept**: Establish a protocol where agents notify each other about task state transitions.
+*   **Implementation**: Task Agent can write state transitions to a shared workspace channel (or lightweight SQLite lockfile) so that concurrent agents do not pick up the same active tasks or attempt conflicting merges.
+
+---
+
+## 3. Recommended Next Steps
+
+> [!IMPORTANT]
+> 1. **Extend `ta init-mcp`**: Implement the `agy` target to facilitate zero-configuration MCP setups.
+> 2. **Build `ta prompt`**: Create a fast, sub-millisecond command suitable for shell prompts to display the active task.
+> 3. **Draft Gemma script**: Write a prototype Python script under `scripts/prioritize_gemma.py` that interfaces with Ollama to sort USV tasks.

task_agent-0.1.490/.task-agent/tasks/completed/2026/add-a-history-function/README.md

@@ -0,0 +1,10 @@
+---
+created_at: 2026-04-05T12:44:39-07:00
+---
+
+# Add a history function
+
+A history command should show a list of the recent completed tasks, in reverse order, and alow view, but not edit.
+
+---
+**Completed in commit:** `59e963c`

task_agent-0.1.490/.task-agent/tasks/completed/2026/add-an-interactive-new/README.md

@@ -0,0 +1,16 @@
+---
+created_at: 2026-04-06T11:06:56-07:00
+---
+
+# Add an interactive new
+
+Allow users to add a new item by opening a new task template for the body.
+
+Have them enter the name at the CLI, and fill that into the new document, along with the date.
+
+Then, but the cursor in the body part.
+
+When they save and close, it should ingest the task, and return back to the terminal.
+
+---
+**Completed in commit:** `2a13572`

task_agent-0.1.490/.task-agent/tasks/completed/2026/add-commit-and-push/README.md

@@ -0,0 +1,10 @@
+---
+created_at: 2026-05-07T12:22:24-07:00
+---
+
+# Add commit and push
+
+Add a ta commit to commit and push all current changes in the tasks/
+
+---
+**Completed in commit:** `<pending-commit-id>`

task_agent-0.1.490/.task-agent/tasks/completed/2026/add-configuration-file-support-for-github-plugin/README.md

@@ -0,0 +1,10 @@
+---
+created_at: 2026-05-15T09:34:12-07:00
+---
+
+# Add configuration file support for GitHub plugin
+
+Allow storing GitHub token and repo in .ta-config.json or worktree-config.json. Add validation for required fields.
+
+---
+**Completed in commit:** `a825289`

task_agent-0.1.490/.task-agent/tasks/completed/2026/add-date-created-to-ta-list-and-ta-prior/README.md

@@ -0,0 +1,14 @@
+---
+created_at: 2026-06-18T18:25:56-07:00
+---
+
+# Add date created to `ta list` and `ta prior`
+
+Add the date to the list. Put it between priorty and status. Make it the same color as "DRAFT". 
+
+## Solution
+
+Added Created date column to ta list and ta prior (cmd_triage) tables between Priority/Pos and Status, styled as dim (same as DRAFT).
+
+---
+**Completed in commit:** `773b2b1`

task_agent-0.1.490/.task-agent/tasks/completed/2026/add-json-switch-to-output-to-json-for-integrations-such-as-nvim/README.md

@@ -0,0 +1,10 @@
+---
+created_at: 2026-03-10T21:57:40-07:00
+---
+
+# Add --json switch to output to JSON for integrations, such as NVim
+
+
+
+---
+**Completed in commit:** `c086307`

task_agent-0.1.490/.task-agent/tasks/completed/2026/add-post-setup-hook-to-ta-init-agent-for-per-repo-secrets/README.md

@@ -0,0 +1,44 @@
+---
+created_at: 2026-06-14T10:03:52-07:00
+---
+
+# Add --post-setup hook to ta init-agent for per-repo secrets
+
+Add a --post-setup <script> flag to ta init-agent that runs an arbitrary script or command after the agent user is fully created (useradd, sudoers, SSH key, template dotfiles). This enables injecting per-repo secrets (GPG keys, npm tokens, custom SSH configs) that aren't in the template.
+
+Context:
+Currently agent setup creates a Linux user, generates SSH keys, materializes template dotfiles, and configures sudoers. But there's no hook for post-creation customization. Teams need a way to inject repo-specific secrets that shouldn't live in the shared template.
+
+Requirements:
+1. Add --post-setup <script> argument to ta init-agent subparser
+2. After agent.init_agent() succeeds, execute the script via subprocess
+3. The script receives the agent username as the first argument (or via AGENT_USER env var)
+4. The script is invoked as the agent user (sudo -u agent_user <script>) so it has access to the agent's home directory
+5. Report stdout/stderr from the script for transparency
+6. If the script exits non-zero, print a warning but don't crash the init
+7. Also add --post-setup to ta start for per-task agents (runs after init_per_task_agent)
+8. Document in docs/task-agents.md with examples
+
+Examples of post-setup scripts:
+- op read "op://team/gpg/private-key" | gpg --import
+- echo "//npm.pkg.github.com/:_authToken=TOKEN" > ~/.npmrc
+- curl -s https://internal-ca.example.com/ca.crt > ~/.local/share/ca-certificates/internal.crt
+
+Implementation notes:
+- For shared agents (ta init-agent): run from cmd_init_agent in cli.py
+- For per-task agents (ta start --agent): run from cmd_start in cli.py after init_per_task_agent
+- Use sudo -u <user> -E to preserve selected env vars if needed
+- The script path can be absolute or relative to cwd
+
+Completion Criteria:
+- --post-setup arg on ta init-agent subparser
+- Script executes as agent user after full setup
+- Script receives AGENT_USER env var
+- Non-zero exit warns but doesn't crash
+- --post-setup also works with ta start --agent
+- Unit tests mocking subprocess.run for post-setup success/failure
+- Documentation with examples in docs/task-agents.md
+- All existing tests pass
+
+---
+**Completed in commit:** `<pending-commit-id>`

task_agent-0.1.490/.task-agent/tasks/completed/2026/add-search-feature/README.md

@@ -0,0 +1,20 @@
+---
+created_at: 2026-04-05T11:07:46-07:00
+---
+
+# Add search feature
+
+The user should be able to search for a task
+
+task-agent should search by slug.
+
+It should match by the begining of the slug, so pattern match with a wildcard end.
+
+If one task is found, task-agent should present that task in view mode and allow edit mode from the view.
+
+If multiple match, present a navigable list and use `l` to select one for viewing, and `h` to go back to the list.
+
+`q` to exit.
+
+---
+**Completed in commit:** `2f481c0`

task_agent-0.1.490/.task-agent/tasks/completed/2026/add-ta-mr-list-and-ta-merge-commands/README.md

@@ -0,0 +1,16 @@
+---
+created_at: 2026-03-22T13:51:44-07:00
+---
+
+# Add ta mr list and ta merge commands
+
+**Depends on:** implement-merge-request-queue
+
+Implement 'ta mr list' to view pending completion notifications and 'ta merge <slug>' to finalize a task (performing the 'ta done' logic of archiving and auto-committing).
+
+## Solution
+
+Implemented 'ta mr list' and 'ta merge <slug>' for reviewable autonomous workflows.
+
+---
+**Completed in commit:** `9dc7634`

task_agent-0.1.490/.task-agent/tasks/completed/2026/add-ta-path-command/README.md

@@ -0,0 +1,14 @@
+---
+created_at: 2026-03-20T20:27:26-07:00
+---
+
+# add ta path command
+
+
+
+## Completion Criteria
+
+Add 'ta path <slug>' command to return the absolute path of a task file.
+
+---
+**Completed in commit:** `3fb0d77`

task_agent-0.1.490/.task-agent/tasks/completed/2026/add-triage-cli-sorting/README.md

@@ -0,0 +1,10 @@
+---
+created_at: 2026-03-12T17:27:53-07:00
+---
+
+# Add Triage CLI sorting
+
+Use j and k to move up and down the list, ctrl+k to move up, p to promote to pending
+
+---
+**Completed in commit:** `fb05124`

task_agent-0.1.490/.task-agent/tasks/completed/2026/add-view-and-edit-features-to-triage/README.md

@@ -0,0 +1,10 @@
+---
+created_at: 2026-03-13T19:02:52-07:00
+---
+
+# Add view and edit features to triage
+
+
+
+---
+**Completed in commit:** `bc097ae`

task_agent-0.1.490/.task-agent/tasks/completed/2026/agent-reports-mcp-access-issue/README.md

@@ -0,0 +1,13 @@
+---
+created_at: 2026-03-14T21:49:38-07:00
+---
+
+# Agent reports MCP access issue
+
+An agent is reporting this error:
+
+
+
+
+---
+**Completed in commit:** `ed61f3b`

task_agent-0.1.490/.task-agent/tasks/completed/2026/agent-sandboxing-via-linux-accounts/README.md

@@ -0,0 +1,224 @@
+---
+created_at: 2026-06-14T10:03:52-07:00
+---
+
+### Task spec: agent-sandboxing-via-linux-accounts
+
+**Replaces:** `integrate-gh-cli-alt-accounts`
+
+---
+
+#### 1. Problem
+
+Agents launched via `ta run` inherit the human's shell environment — `direnv`,
+`mise`, and cached credentials loaded in the human's session. This means an
+agent can accidentally deploy to PROD if PROD credentials happen to be loaded
+or cached.
+
+The current `GH_CONFIG_DIR` approach isolates GitHub CLI tokens only. It
+doesn't address AWS, Azure, GCP, Kubernetes, or any other PROD credentials.
+A proper solution must make the agent **PROD-incompetent by construction**.
+
+---
+
+#### 2. Solution
+
+Run agent processes as a dedicated Linux user. The agent user has its own home
+directory with only UAT/non-PROD credentials configured. It physically lacks
+the SSH keys, cloud profiles, and tokens needed to access PROD.
+
+```
++--------------------+         +----------------------------+
+| Human (mark)       |         | Agent (agent-{template})   |
+|                    |         |                            |
+| ~/.ssh/id_ed25519  |         | ~/.ssh/agent_ed25519       |
+| ~/.config/gh/human |         | ~/.config/gh/agent         |
+| ~/.aws/prod        |         | ~/.aws/uat                 |
+| PROD credentials   |         | UAT-only credentials       |
++--------------------+         +----------------------------+
+         \                              /
+          \                            /
+           git push to bare remote    /
+            \                        /
+             \                      /
+          +---------------------------+
+          |  /srv/git/repo.git        |
+          |  (common bare remote)     |
+          +---------------------------+
+```
+
+**Key invariant:** The agent Linux user's home directory contains only
+non-PROD credentials. There is no way for the agent to accidentally deploy to
+PROD — it simply doesn't have the keys.
+
+---
+
+#### 3. Phase 1 — Core isolation
+
+**`ta init-agent <name>`** — New command that:
+
+1. Creates a Linux user (`sudo adduser --system agent-<name>`)
+2. Generates an SSH key for the agent user
+3. Configures `~agent-<name>/.gitconfig` with agent identity
+4. Sets up `~agent-<name>/.config/gh/` (optional, prompted)
+5. Installs a sudoers drop-in: `human ALL=(agent-<name>) NOPASSWD: /path/to/ta`
+6. Outputs a summary of what was created
+
+**`ta run` changes:**
+
+Worker is launched via `sudo -u agent-<name>` rather than directly.
+Environment variables (`TA_SLUG`, `TA_FILE`, `TA_ROOT`) are passed explicitly
+via `env` on the sudo command line. Working directory is set to the worktree
+path via `--chdir`.
+
+```python
+# Current
+subprocess.run([str(worker)], env=env)
+
+# New
+subprocess.run([
+    "sudo", "-u", agent_user,
+    "--chdir", str(worktree_path),
+    "env", f"TA_SLUG={slug}", f"TA_FILE={file}", f"TA_ROOT={root}",
+    str(worker)
+])
+```
+
+**`ta start` changes:**
+
+- After creating the worktree at `.gwt/{slug}/`, sets group permissions:
+  - `chown -R :agent-<name> .gwt/{slug}/`
+  - `chmod -R g+rwX .gwt/{slug}/`
+- If the agent user needs to create the worktree, uses
+  `sudo -u agent-<name> git worktree add`
+
+**`~agent-<name>/.gitconfig`:**
+
+```ini
+[user]
+    name = Agent Name
+    email = agent@domain.com
+[safe]
+    directory = /home/mark/repo/.gwt/*
+```
+
+The `safe.directory` entry prevents Git from refusing to operate in the
+worktree (owned by human).
+
+**Worktree filesystem layout:**
+
+```
+.gwt/{slug}/               # owned by human
+  group: agent-<name>       # agent group can read/write
+  permissions: 2775         # setgid bit so new files inherit group
+```
+
+**`~agent-<name>/.local/bin/uv`:** On init, `uv` is symlinked into the agent
+user's `~/.local/bin/` so the agent can run `uv`-based worker scripts without
+requiring the human's PATH.
+
+**`~agent-<name>/.profile`:** Created with a PATH entry that adds
+`~/.local/bin`, so login shells (`bash -l`) resolve `uv` and future tooling.
+
+**`ta run --agent` invocation:** Uses `bash -l -c` instead of `sh -c` so the
+agent's `.profile` is sourced before running the worker:
+
+```python
+subprocess.run([
+    "sudo", "-u", agent_user,
+    "bash", "-l", "-c",
+    "cd <worktree> && exec env TA_SLUG=... TA_FILE=... TA_ROOT=... <worker>"
+])
+```
+
+---
+
+**Subtasks:**
+
+- Phase 2 — Agent templates (`docs/tasks/draft/phase-2-agent-templates/`)
+  - **Depends on:** this task
+  - Template system for `ta init-agent --template <name>`
+- Phase 3 — Per-task isolation (`docs/tasks/draft/phase-3-per-task-isolation/`)
+  - **Depends on:** this task, phase-2-agent-templates
+  - `ta start --agent <template>` creates a dedicated agent per task
+
+---
+
+#### 6. Design decisions
+
+| Decision | Choice | Rationale |
+|---|---|---|
+| User creation method | `sudo adduser --system` | Consistent, scriptable, no interactive prompts |
+| Agent invocation | `sudo -u agent-<name> bash -l -c "cd <worktree> && exec env ... <worker>"` | Login shell sources profile for PATH; `exec env` passes task env vars explicitly |
+| Worktree ownership | Human + group agent | Human can read/write, agent can read/write via group |
+| Credential provisioning | `op://` at init time, static files at runtime | No 1Password dependency during agent execution |
+| Template storage | `.ta/agents/<name>/` in project repo | Version-controlled, shareable across team |
+| Tool discovery | Symlink `uv` into `~agent/.local/bin/` at init time | Agent finds tools without inheriting human PATH |
+
+---
+
+#### 7. Open questions
+
+1. **Default agent.** Should `ta run` (without `--agent`) use a default agent
+   user? If so, how is it configured?
+2. **Cleanup.** Should there be a `ta destroy-agent <name>` that removes the
+   Linux user and cleans up?
+3. **Non-Linux.** macOS has no `adduser --system`. Should we skip, or
+   implement via `sysadminctl`?
+4. **Worktree creation.** Should `ta start` create the worktree as the human
+   or the agent? Human is simpler for the initial implementation.
+5. **Multiple agents.** Can a single worktree be used by multiple agent users
+   simultaneously? (Probably no — single agent per worktree.)
+
+---
+
+#### 8. Files affected
+
+| File | Change |
+|---|---|
+| `src/taskagent/agent.py` | New module — `init_agent()`, `destroy_agent()`, user management, worktree permissions, profile/tool provisioning |
+| `src/taskagent/cli.py` | Add `cmd_init_agent()`, modify `cmd_run()` (sudo + bash -l -c) and `cmd_start()` (chgrp) |
+| `src/taskagent/mcp.py` | `run_task`, `complete_task` tools need agent user context (minor) |
+| `tests/test_agent.py` | Unit tests for agent module |
+| `docs/tasks/active/agent-sandboxing-via-linux-accounts/README.md` | This spec |
+| `tests/e2e/test_agent_sandboxing.sh` | End-to-end test script |
+
+---
+
+#### 9. Completion Criteria
+
+**Phase 1 — Core isolation:**
+
+1. `ta init-agent <name>` creates a Linux user with:
+   - SSH key in `~agent-<name>/.ssh/`
+   - Git config in `~agent-<name>/.gitconfig`
+   - `~agent-<name>/.profile` adding `~/.local/bin` to PATH
+   - `uv` symlinked into `~agent-<name>/.local/bin/uv`
+   - Sudoers drop-in for passwordless ta/worker execution
+   - Summary output of what was created
+   - Graceful error if sudo is unavailable
+
+2. `ta start --agent <name>` sets worktree permissions (group + ACL) so the
+   agent user can read and write the worktree.
+
+3. `ta run` for an active (or pending/draft) task executes the worker via
+   `sudo -u <agent>` with environment variables (`TA_SLUG`, `TA_FILE`,
+   `TA_ROOT`) passed explicitly on the command line, not inherited.
+
+4. All existing tests continue to pass.
+
+5. New unit tests cover:
+   - Sudo invocation arguments and working directory
+   - `adduser`/`useradd` invocation arguments
+   - Graceful failure when sudo is unavailable
+   - Graceful failure when agent user doesn't exist
+   - Worktree permission setup
+
+6. New e2e test at `tests/e2e/test_agent_sandboxing.sh` covers:
+   - Full lifecycle: `init-agent` → `ta new` → `ta start --agent` →
+     `ta run` → verify agent user context → `destroy-agent`
+   - E2e test runs in CI on Ubuntu (container or VM)
+   - E2e test must pass before the task is accepted
+
+---
+**Completed in commit:** `<pending-commit-id>`

task_agent-0.1.490/.task-agent/tasks/completed/2026/agents-report-commands-are-hanging/README.md

@@ -0,0 +1,14 @@
+---
+created_at: 2026-06-19T11:10:33.219725-07:00
+---
+
+# Agents report commands are hanging
+
+I am getting reports like this:
+
+> It looks like the tool use was rejected rather than hanging. This is similar to the earlier issue we had where task-agent's auto-commit failed because the working tree was already clean (we had committed manually).
+
+How can we improve the reliability of the command that might involve git commits on repos that might have commit hooks?
+
+---
+**Completed in commit:** `380e073`

task_agent-0.1.490/.task-agent/tasks/completed/2026/allow-dots-in-task-slugs-for-numeric-hierarchies/README.md

@@ -0,0 +1,38 @@
+---
+created_at: 2026-06-14T10:03:52-07:00
+---
+
+# Allow dots in task slugs for numeric hierarchies
+
+The `slugify` method in `manager.py` uses the regex `[^\w\s-]` which strips dots from task titles. This prevents agents from using numeric hierarchy notation like `1.1`, `1.2`, `2.1` etc. in task titles, which some agents natively produce when decomposing work.
+
+**Problem:**
+- `slugify()` at `manager.py:224` removes all non-word characters including `.`
+- `slugify('1.1 Setup CI')` → `1-1-setup-ci` instead of `1.1-setup-ci`
+- This breaks round-trip fidelity when an agent generates a numbered task breakdown and the slugs lose their structural hierarchy
+
+**Solution:**
+- Add `.` to the allowed character set in `slugify()`, e.g. `[^\w\s.-]`
+- Audit all downstream consumers of slugs to ensure dots don't break:
+  - `find_issue_file()` — uses file globs and path joins; dots in directory names are valid on all OS
+  - `mission.usv` parser — uses USV (`\x1f`) delimiter, not dot-separated
+  - `move_to_active()` / worktree paths — dots in branch/worktree names are valid in git
+  - `complete_issue()` — stores in `completed/` directories; dots are valid
+  - `soft_delete_issue()` — stores in `deleted/`; dots are valid
+- Add unit tests for slugify with dot-containing titles
+- Add an integration test: create a task titled `1.1 Test Task`, verify slug is `1.1-test-task`, verify file operations succeed
+
+**Risk:**
+- Existing slugs won't change (they have no dots).
+- `find_issue_file()` uses `glob(f\"{slug}.*\")` which could match multiple entries if other files contain the slug as a prefix with dot. But this is the same risk as any existing slug (e.g. `foo` matching `foo.md` vs `foo-bar.md`). No regression.
+
+**Completion Criteria:**
+- [ ] `slugify()` updated to preserve `.` characters
+- [ ] All downstream slug consumers verified for dot-compatibility
+- [ ] Existing test suite passes (no regressions from dot-allowing)
+- [ ] New unit tests for dot-slug variants
+- [ ] Manual test: `ta new '1.1 Test Task' && ta list` shows slug `1.1-test-task`
+- [ ] Manual test: worktree creation with a dot-containing slug works
+
+---
+**Completed in commit:** `<pending-commit-id>`