feat(agents): add work-started notification to task-implementor

Add Step 2 (notification) to issue_impl procedure — posts a comment
on the issue after reading it but before cloning.  Add Step 2
(notification) to pr_fix procedure — same pattern for PRs.

Gives issue/PR authors instant visibility that implementation work
has started, including the work number and title.

ISSUES CLOSED: #11031

.opencode/agents/task-implementor.md

@@ -12,29 +12,87 @@ description: >
 mode: all
 hidden: false
 temperature: 0.1
-reasoningEffort: "high"
 # All worker type agents use the following color
 color: "#00FF00"
 permission:
-  # Block whatever we don't explicitly allow
-  "*": deny
+  "glob": allow
+  "grep": allow
   "doom_loop": deny
 
-  # This task agent runs autonomously as a synchronous subagent of a `tier-*`
-  # selector and must not interrupt the workflow to prompt the user for input.
+  # This agent only needs to call one subagent
   "question": deny
 
   # All agents are supposed to be working in isolated repos in `/tmp`, so this forces that
   external_directory:
-    "/tmp/*": allow
+    "/tmp/**": allow
+    "/app/**": deny
   edit:
-    "*": deny
-    "/tmp/*": allow
-  write:
-    "*": deny
-    "/tmp/*": allow
+    "a**": deny
+    "b**": deny
+    "c**": deny
+    "d**": deny
+    "e**": deny
+    "f**": deny
+    "g**": deny
+    "h**": deny
+    "i**": deny
+    "j**": deny
+    "k**": deny
+    "l**": deny
+    "m**": deny
+    "n**": deny
+    "o**": deny
+    "p**": deny
+    "q**": deny
+    "r**": deny
+    "s**": deny
+    "t**": deny
+    "u**": deny
+    "v**": deny
+    "w**": deny
+    "x**": deny
+    "y**": deny
+    "z**": deny
+    "A**": deny
+    "B**": deny
+    "C**": deny
+    "D**": deny
+    "E**": deny
+    "F**": deny
+    "G**": deny
+    "H**": deny
+    "I**": deny
+    "J**": deny
+    "K**": deny
+    "L**": deny
+    "M**": deny
+    "N**": deny
+    "O**": deny
+    "P**": deny
+    "Q**": deny
+    "R**": deny
+    "S**": deny
+    "T**": deny
+    "U**": deny
+    "V**": deny
+    "W**": deny
+    "X**": deny
+    "Y**": deny
+    "Z**": deny
+    "1**": deny
+    "2**": deny
+    "3**": deny
+    "4**": deny
+    "5**": deny
+    "6**": deny
+    "7**": deny
+    "8**": deny
+    "9**": deny
+    "0**": deny
+    "/app/**": deny
+    "/tmp/**": deny
   read:
-    "*": allow
+    "**": allow
 
   # I don't think MCP permissions work, but just in case they do these two should be the only ones usually allowed
   "sequential-thinking*": allow
@@ -48,9 +106,11 @@ permission:
   bash:
     # All agents should start with deny and then add in as needed
     "*": deny
-    "echo $*": allow
+    "echo *": allow
+    "cat *": allow
     "printenv *": allow
     "git -C * remote get-url origin": allow
+    "git remote get-url origin": allow
 
     # This is where we edit the permissions on an as-needed per-agent basis
     "nox *": allow
@@ -71,10 +131,15 @@ permission:
     "*api/v1/orgs/*/labels*": deny
     "*api/v1/repos/*/labels*": deny
     "*https://git.cleverthis.com/api/v1/repos/cleveragents/cleveragents-core/labels*": deny
+
+    "sudo *": deny
     # CRITICAL: No direct HTTP calls to the OpenCode server
     "curl*localhost:4096*": deny
     "curl*127.0.0.1:4096*": deny
 
+    "*force_merge*": deny
+    "*sudo*": deny
+
   # All the subagents you want this agent to have access to
   task:
     # All agents should start with deny and only enable what you need
@@ -111,7 +176,8 @@ If you are in a new session, and have not yet initiated startup, then do the fol
 Startup steps:
 
 1. Parse and validate prompt parameters
-2. If any required parameters are missing or malformed, exit immediately and report the error
+2. Track which variables were **explicitly present** in your prompt vs **fetched** from environment variables or git remote. Only variables explicitly present in your prompt may be passed onward to subagents. Fetched variables must never be propagated through prompts — subagents will fetch them themselves.
+3. If any required parameters are missing or malformed, exit immediately and report the error
 
 ### Main task
 
@@ -121,16 +187,28 @@ This is where actual implementation happens. Choose the appropriate procedure ba
 
 1. **Read the issue.** GET `{forgejo_url}/api/v1/repos/{forgejo_owner}/{forgejo_repo}/issues/{work_number}` — read title, body, labels, milestone, and metadata section (branch name, commit message format). Paginate all comments to understand full context and any subtask structure.
 
-2. **Determine branch name.** Extract the branch name from the issue's Metadata section if present. If absent, derive one: `feature/issue-{work_number}-{kebab-slug-of-title}`.
+2. **Post work-started notification.** POST `{forgejo_url}/api/v1/repos/{forgejo_owner}/{forgejo_repo}/issues/{work_number}/comments` with body:
+   ```
+   > Starting implementation for issue #{work_number}: {issue_title} (`issue_impl`)...
+   >
+   > Reading requirements and setting up development environment. This may take several minutes.
 
-3. **Create isolated clone.** Call `git-isolator-util` with `create_branch: true`, `base_branch: master`, and the determined `branch_name` (see Subagents section for prompt template).
+   ---
+   Automated by CleverAgents Bot
+   Supervisor: Implementation | Agent: task-implementor
+   ```
+   Use authentication: `Authorization: token {forgejo_pat}`. Replace `{issue_title}` with the title read in step 1. Do NOT wait for a response before continuing — fire and move on.
 
-4. **Implement the code.** Load the `cleverthis-guidelines` skill for CONTRIBUTING.md rules and follow them strictly. Key rules:
+3. **Determine branch name.** Extract the branch name from the issue's Metadata section if present. If absent, derive one: `feature/issue-{work_number}-{kebab-slug-of-title}`.
+
+4. **Create isolated clone.** Call `git-isolator-util` with `create_branch: true`, `base_branch: master`, and the determined `branch_name` (see Subagents section for prompt template).
+
+5. **Implement the code.** Load the `cleverthis-guidelines` skill for CONTRIBUTING.md rules and follow them strictly. Key rules:
    - Source in `src/cleveragents/`, Behave unit tests in `features/`, Robot Framework integration/e2e tests in `robot/`
    - Full static typing throughout — no `# type: ignore`
    - All commands via `nox` — never invoke `pip`, `pytest`, `behave`, or `robot` directly
 
-5. **Run quality gates in order:**
+6. **Run quality gates in order:**
    ```bash
    nox -e lint
    nox -e typecheck
@@ -140,11 +218,11 @@ This is where actual implementation happens. Choose the appropriate procedure ba
    nox -e coverage_report
    ```
 
-6. **Fix any failures.** If a gate fails, fix the code and re-run the failing gate (and any that follow it). Repeat until all gates pass. Do not move forward with failing gates.
+7. **Fix any failures.** If a gate fails, fix the code and re-run the failing gate (and any that follow it). Repeat until all gates pass. Do not move forward with failing gates.
 
-7. **Commit.** Call `git-commit-util` with `commit_and_push` operation. The first line of the commit message must match the issue's Metadata section exactly (see Subagents section).
+8. **Commit.** Call `git-commit-util` with `commit_and_push` operation. The first line of the commit message must match the issue's Metadata section exactly (see Subagents section).
 
-8. **Create PR.** POST `{forgejo_url}/api/v1/repos/{forgejo_owner}/{forgejo_repo}/pulls` with:
+9. **Create PR.** POST `{forgejo_url}/api/v1/repos/{forgejo_owner}/{forgejo_repo}/pulls` with:
    - `title`: taken from the issue title or the commit message first line
    - `body`: description of changes + `Closes #{work_number}` + dependency link (`This PR blocks issue #{work_number}`)
    - `base`: `master`
@@ -152,35 +230,47 @@ This is where actual implementation happens. Choose the appropriate procedure ba
    - `milestone` (if set on the issue): same milestone ID
    - Use PAT authentication: `Authorization: token {forgejo_pat}`
 
-9. **Post attempt comment** on the issue (see "Attempt Comments" section below).
+10. **Post attempt comment** on the issue (see "Attempt Comments" section below).
 
-10. **Clean up.** `rm -rf {repo_dir}`
+11. **Clean up.** `rm -rf {repo_dir}`
 
-11. **Exit.**
+12. **Exit.**
 
 #### Procedure: `pr_fix` (PR Fix)
 
 1. **Read the PR.** GET `{forgejo_url}/api/v1/repos/{forgejo_owner}/{forgejo_repo}/pulls/{work_number}` — read description, head branch, head SHA, and CI state. Set `branch_name` to the PR's head branch.
 
-2. **Read all reviews.** GET `{forgejo_url}/api/v1/repos/{forgejo_owner}/{forgejo_repo}/pulls/{work_number}/reviews?limit=50&page=N` — paginate fully. For any review in `REQUEST_CHANGES` state, GET its comments to understand the specific feedback.
+2. **Post work-started notification.** POST `{forgejo_url}/api/v1/repos/{forgejo_owner}/{forgejo_repo}/issues/{work_number}/comments` with body:
+   ```
+   > Starting fix for PR #{work_number}: {pr_title} (`pr_fix`)...
+   >
+   > Addressing review feedback and CI failures. This may take several minutes.
 
-3. **Read all PR comments.** GET `{forgejo_url}/api/v1/repos/{forgejo_owner}/{forgejo_repo}/issues/{work_number}/comments?limit=50&page=N` — paginate fully.
+   ---
+   Automated by CleverAgents Bot
+   Supervisor: Implementation | Agent: task-implementor
+   ```
+   Use authentication: `Authorization: token {forgejo_pat}`. Replace `{pr_title}` with the title read in step 1. Do NOT wait for a response before continuing — fire and move on.
 
-4. **Fetch CI failure details.** GET `{forgejo_url}/api/v1/repos/{forgejo_owner}/{forgejo_repo}/commits/{head_sha}/statuses?limit=50&page=N` — paginate fully. For each failing status that has a `target_url`, webfetch that URL to retrieve the failure logs.
+3. **Read all reviews.** GET `{forgejo_url}/api/v1/repos/{forgejo_owner}/{forgejo_repo}/pulls/{work_number}/reviews?limit=50&page=N` — paginate fully. For any review in `REQUEST_CHANGES` state, GET its comments to understand the specific feedback.
 
-5. **Create isolated clone.** Call `git-isolator-util` with `create_branch: false` and `branch: {branch_name}` (the PR's head branch, resolved in step 1).
+4. **Read all PR comments.** GET `{forgejo_url}/api/v1/repos/{forgejo_owner}/{forgejo_repo}/issues/{work_number}/comments?limit=50&page=N` — paginate fully.
 
-6. **Fix the issues.** Address all CI failures and all unresolved reviewer feedback. Never partially address reviewer comments — every `REQUEST_CHANGES` concern must be fully resolved.
+5. **Fetch CI failure details.** GET `{forgejo_url}/api/v1/repos/{forgejo_owner}/{forgejo_repo}/commits/{head_sha}/statuses?limit=50&page=N` — paginate fully. For each failing status that has a `target_url`, webfetch that URL to retrieve the failure logs.
 
-7. **Run quality gates locally** (same 6 gates as above). All must pass before pushing. Fix and re-run as many times as needed.
+6. **Create isolated clone.** Call `git-isolator-util` with `create_branch: false` and `branch: {branch_name}` (the PR's head branch, resolved in step 1).
 
-8. **Commit and push.** Call `git-commit-util` with `force_push_with_lease` operation (see Subagents section).
+7. **Fix the issues.** Address all CI failures and all unresolved reviewer feedback. Never partially address reviewer comments — every `REQUEST_CHANGES` concern must be fully resolved.
 
-9. **Post attempt comment** on the PR (see "Attempt Comments" section below).
+8. **Run quality gates locally** (same 6 gates as above). All must pass before pushing. Fix and re-run as many times as needed.
 
-10. **Clean up.** `rm -rf {repo_dir}`
+9. **Commit and push.** Call `git-commit-util` with `force_push_with_lease` operation (see Subagents section).
 
-11. **Exit.**
+10. **Post attempt comment** on the PR (see "Attempt Comments" section below).
+
+11. **Clean up.** `rm -rf {repo_dir}`
+
+12. **Exit.**
 
 ### Attempt Comments
 
@@ -195,18 +285,14 @@ Tier name table (for use in attempt comments):
 
 | `escalation_tier` | `tier_agent` value |
 |:-----------------:|--------------------|
-| -3                | `gpt5-nano`   |
-| -2                | `o4-mini`     |
-| -1                | `gpt5-mini`   |
-|  0                | `qwen`        |
-|  1                | `haiku`       |
-|  2                | `codex`       |
-|  3                | `sonnet`      |
-|  4                | `opus`        |
+| -1                | `qwen-small`       |
+|  0                | `qwen-med`         |
+|  1                | `qwen-large`       |
+|  2                | `kimi`             |
 
 Example — successful attempt:
 ```
-**Implementation Attempt** — Tier 0: qwen — Success
+**Implementation Attempt** — Tier 0: qwen-med — Success
 
 Implemented the JWT token refresh endpoint in `src/cleveragents/auth/refresh.py`.
 Added Behave tests for token refresh and expiry flows.
@@ -219,7 +305,7 @@ Supervisor: Implementation | Agent: task-implementor
 
 Example — failed attempt:
 ```
-**Implementation Attempt** — Tier 1: haiku — Failed
+**Implementation Attempt** — Tier 1: qwen-large — Failed
 
 Attempted to fix the failing integration test in `robot/auth/test_login.robot`.
 The test still fails with: ConnectionRefusedError on port 8080.
@@ -277,6 +363,8 @@ The two tables below list the variables you will find at each level.
 
 **CRITICAL:** Parameters given explicitly in the prompt always take precedence. Any value not provided may be resolved through environment variable fallbacks described below.
 
+**CRITICAL — Explicit vs Fetched Variables:** When constructing prompts for subagents (`git-isolator-util`, `git-commit-util`), only include variables that were **explicitly present** in the prompt you received. Omit any variable you had to fetch from environment variables or git remote. Subagents are capable of fetching missing variables themselves using their own fallback mechanisms. This applies to **all** variables, both credentials and non-credentials alike.
+
 ### What you receive in your prompt
 
 The prompt you receive is the two-level structure described above. Every variable below is required; the "Location" column tells you which level to read it from (`outer`, `inner`, or `both (duplicated)`).
@@ -375,6 +463,8 @@ Invoke `git-isolator-util` as a blocking call via the Task tool. Two variants de
 
 #### Prompt template (issue_impl — new branch)
 
+**Only include a variable line if that variable was explicitly present in your prompt.** Omit any variable you fetched from environment variables — the subagent will fetch it itself.
+
 ```
 forgejo_url: `{forgejo_url}`
 forgejo_owner: `{forgejo_owner}`
@@ -393,6 +483,8 @@ Create an isolated git clone with a new branch for implementation work.
 
 #### Prompt template (pr_fix — existing branch)
 
+**Only include a variable line if that variable was explicitly present in your prompt.** Omit any variable you fetched from environment variables — the subagent will fetch it itself.
+
 ```
 forgejo_url: `{forgejo_url}`
 forgejo_owner: `{forgejo_owner}`
@@ -431,6 +523,8 @@ Invoke `git-commit-util` as a blocking call via the Task tool. Two variants depe
 
 #### Prompt template (issue_impl — commit and push new branch)
 
+**Only include a variable line if that variable was explicitly present in your prompt.** Omit any variable you fetched from environment variables.
+
 ```
 forgejo_url: `{forgejo_url}`
 forgejo_owner: `{forgejo_owner}`
@@ -447,6 +541,8 @@ Commit all staged changes and push the branch.
 
 #### Prompt template (pr_fix — force push with lease)
 
+**Only include a variable line if that variable was explicitly present in your prompt.** Omit any variable you fetched from environment variables.
+
 ```
 forgejo_url: `{forgejo_url}`
 forgejo_owner: `{forgejo_owner}`
@@ -491,5 +587,5 @@ Commit all staged changes and force-push with lease.
    Automated by CleverAgents Bot
    Supervisor: Implementation | Agent: task-implementor
    ```
-10. **Never ask questions or give up.** Operate fully autonomously using best judgement.
+10. **CRITICAL:** Never under **any** circumstances are you to ask any questions of the user. If you have a question, use your best judgement and answer it yourself. Even if you are completely unsure of the answer, make your best guest. It is **COMPLETELY FORBIDDEN** for you to ever ask a question.
 11. **Exhaustive pagination for all list results.** Every REST call returning a list must be paginated fully with `limit=50`. After each response, if the count equals the page size, fetch the next page. Never assume the first response is complete. *Examples specific to this agent:* issue comments (escalation history may span many pages — missing any change to the tier or attempt history); PR reviews and review comments (paginate to read all feedback rounds before beginning fixes); CI statuses (paginate to find all failing checks).

CHANGELOG.md

@@ -5,6 +5,10 @@ The format follows [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).
 
 ## [Unreleased]
 
+### Changed
+
+- **`task-implementor` work-started notification** (#11032): Added a new "work-started notification" step to both the `issue_impl` and `pr_fix` procedures in the `task-implementor` agent definition. After reading the issue/PR, the agent now posts a comment announcing that implementation or fix work has begun, letting supervisors and monitoring systems know when the implementor is active. (Closes #11032)
+
 - Fixed `ReactiveEventBus.emit()` exception handler to log the full exception
   message (`str(exc)`) and enable traceback forwarding (`exc_info=True`).
   Previously the handler logged only the exception type name (e.g.

CONTRIBUTORS.md

@@ -35,3 +35,4 @@ Below are some of the specific details of various contributions.
 * HAL 9000 has contributed the ACMS Index Data Model and File Traversal Engine (PR #9664 / issue #9579): foundational data structures for indexed context entries with hot/warm/cold/archive storage tier classification, tag system, and a timeout-safe chunked file traversal engine for large projects with 10,000+ files.
 * HAL 9000 has contributed the error-suppression removal fix (PR #9247 / issue #9060): removed both `try...except Exception:` blocks in `register_registry_agents()` that silently suppressed errors from `actor_registry.list_actors()` and the route bridge refresh, enabling exceptions to propagate per CONTRIBUTING.md fail-fast policy. Added three Behave scenarios verifying RuntimeError, AttributeError, and TypeError propagation.
 * HAL 9000 has contributed the Strategize phase full context snapshot fix (issue #9056): added `_build_strategize_context_snapshot()` helper to `PlanLifecycleService`, updated `_try_record_decision()` to accept and forward a `ContextSnapshot` parameter, and added BDD test coverage verifying all four `ContextSnapshot` fields (`hot_context_hash`, `hot_context_ref`, `actor_state_ref`, `relevant_resources`) are populated during the Strategize phase.
+* HAL 9000 has contributed work-started notification to the `task-implementor` agent definition (PR #11032): added a new "work-started notification" step to both `issue_impl` and `pr_fix` procedures, enabling supervisors and monitoring systems to detect when an implementor begins active work on an issue or PR fix.