Rename implementation agent to code agent across the repo

dispatch/github/actions/fullsend/action.yml

@@ -9,7 +9,7 @@ branding:
 
 inputs:
   stage:
-    description: Pipeline stage passed to fullsend (e.g. triage, implementation, review).
+    description: Pipeline stage passed to fullsend (e.g. triage, code, review).
     required: true
   scm:
     description: Value for fullsend --scm (optional; defaults to github).

dispatch/github/workflows/implementation.yml → dispatch/github/workflows/code.yml

@@ -1,4 +1,4 @@
-name: Implementation
+name: Code
 
 on:
   issues:
@@ -7,17 +7,17 @@ on:
     types: [created]
 
 concurrency:
-  group: fullsend-implementation-${{ github.event.issue.number }}
+  group: fullsend-code-${{ github.event.issue.number }}
   cancel-in-progress: true
 
 jobs:
-  implementation:
-    name: Implementation
+  code:
+    name: Code
     if: |
-      (github.event_name == 'issues' && github.event.action == 'labeled' && github.event.label.name == 'ready-to-implement') ||
+      (github.event_name == 'issues' && github.event.action == 'labeled' && github.event.label.name == 'ready-to-code') ||
       (github.event_name == 'issue_comment' && (
-        startsWith(github.event.comment.body || '', '/implement ') ||
-        (github.event.comment.body || '') == '/implement'
+        startsWith(github.event.comment.body || '', '/code ') ||
+        (github.event.comment.body || '') == '/code'
       ))
     runs-on: ubuntu-latest
     permissions:
@@ -29,16 +29,16 @@ jobs:
       - name: Checkout repository
         uses: actions/checkout@v4
         with:
-          token: ${{ secrets.FULLSEND_IMPLEMENTATION_BOT_TOKEN }}
+          token: ${{ secrets.FULLSEND_CODE_BOT_TOKEN }}
           fetch-depth: 1
 
       - name: Setup agent environment
         env:
-          STAGE_PREFIX: IMPLEMENTATION_
-          IMPLEMENTATION_FULLSEND_IMPLEMENTATION_BOT_TOKEN: ${{ secrets.FULLSEND_IMPLEMENTATION_BOT_TOKEN }}
+          STAGE_PREFIX: CODE_
+          CODE_FULLSEND_CODE_BOT_TOKEN: ${{ secrets.FULLSEND_CODE_BOT_TOKEN }}
         run: bash .github/scripts/setup-agent-env.sh
 
-      - name: Run implementation agent(s)
+      - name: Run code agent(s)
         uses: ./.github/actions/fullsend
         with:
-          stage: implementation
+          stage: code

docs/architecture.md

@@ -31,7 +31,7 @@ Infrastructure platform choice and configuration are specified in the adopting o
 **Open questions:**
 
 - Do we adopt a 3rd party platform, use existing internal infrastructure, or build our own? (See [agent-infrastructure.md](problems/agent-infrastructure.md) for the three directions.)
-- Can different agent types (short-lived review vs. long-running implementation) run on different infrastructure?
+- Can different agent types (short-lived review vs. long-running code) run on different infrastructure?
 - Who in the org owns and operates this, and how does it relate to existing platform or CI ownership?
 - Should model and MCP (or other tool-protocol) traffic from agent runtimes go through a **shared gateway** for authentication, spend limits, allowlists, and telemetry? (See [landscape.md](landscape.md#agent-gateway).)
 
@@ -104,7 +104,7 @@ The existing design principle is that [the repo is the coordinator](problems/age
 
 **Open questions:**
 
-- Is GitHub's event system sufficient, or do we need additional coordination logic (e.g. to prevent two implementation agents from picking up the same issue)?
+- Is GitHub's event system sufficient, or do we need additional coordination logic (e.g. to prevent two code agents from picking up the same issue)?
 - How does work assignment interact with the backlog/priority agent described in [agent-architecture.md](problems/agent-architecture.md)?
 - What happens when work needs to be cancelled, retried, or reassigned?
 - Does the coordinator need state (a queue, a lock, a claim system), or can it be stateless and event-driven?
@@ -177,7 +177,7 @@ ADR 0002: [Building block 1](ADRs/0002-initial-fullsend-design.md#1-webhook--dis
 
 ### 2. Slash-command parser + ACL
 
-Parses `/triage`, `/implement`, `/review`, and related commands and enforces who is allowed to invoke each.
+Parses `/triage`, `/code`, `/review`, and related commands and enforces who is allowed to invoke each.
 ADR 0002: [Building block 2](ADRs/0002-initial-fullsend-design.md#2-slash-command-parser--acl).
 
 ### 3. Label state machine guard
@@ -205,19 +205,19 @@ ADR 0002: [Building block 6](ADRs/0002-initial-fullsend-design.md#6-repro-sandbo
 Formats triage test artifacts in repo-native conventions for PR handoff.
 ADR 0002: [Building block 7](ADRs/0002-initial-fullsend-design.md#7-test-artifact-formatter).
 
-### 8. implementation agent runtime
+### 8. code agent runtime
 
 Implements changes, runs local/CI-equivalent tests, handles check failures, and advances handoff to **Review** (`ready-for-review`).
 ADR 0002: [Building block 8](ADRs/0002-initial-fullsend-design.md#8-implementation-agent-runtime).
 
 ### 9. PR sandbox / CI mirror
 
-Execution environment for **Implementation** and test loops, aligned to contributor/CI toolchains.
+Execution environment for **Code** and test loops, aligned to contributor/CI toolchains.
 ADR 0002: [Building block 9](ADRs/0002-initial-fullsend-design.md#9-pr-sandbox--ci-mirror).
 
 ### 10. Check failure triage
 
-Fetches and classifies failing check logs to guide **implementation agent** remediation loops.
+Fetches and classifies failing check logs to guide **code agent** remediation loops.
 ADR 0002: [Building block 10](ADRs/0002-initial-fullsend-design.md#10-check-failure-triage).
 
 ### 11. review agent runtime
@@ -230,12 +230,12 @@ ADR 0002: [Building block 11](ADRs/0002-initial-fullsend-design.md#11-review-age
 Aggregates review verdicts and applies labels:
 
 - unanimous approve-merge → `ready-for-merge` (for the **current** PR head at the end of that round only)
-- unanimous rework → `ready-to-implement`
+- unanimous rework → `ready-to-code`
 - split/conflicting (including conflicting security severities) → `requires-manual-review`
 - each **review run start** (including push-triggered re-review) clears **`ready-for-merge`** together with **`ready-for-review`** so merge approval is never stale after new commits
 ADR 0002: [Building block 12](ADRs/0002-initial-fullsend-design.md#12-coordinator-merge-algorithm).
 
 ### 13. Observability
 
-Traceability layer across issue, **Triage**, **Implementation**, **Review**, checks, and merge for incident response and correlation across automation runs.
+Traceability layer across issue, **Triage**, **Code**, **Review**, checks, and merge for incident response and correlation across automation runs.
 ADR 0002: [Building block 13](ADRs/0002-initial-fullsend-design.md#13-observability).

docs/glossary.md

@@ -15,7 +15,7 @@ See [architecture.md](architecture.md) and [agent-infrastructure.md](problems/ag
 
 ### Agent Registry
 
-The catalog of available agent roles and their configurations. It bridges the abstract roles defined in the agent architecture (triage, implementation, review) and the concrete runtime configurations the harness uses to instantiate each agent. Fullsend provides a base set; adopting organizations extend it via their `.fullsend` repository.
+The catalog of available agent roles and their configurations. It bridges the abstract roles defined in the agent architecture (triage, code, review) and the concrete runtime configurations the harness uses to instantiate each agent. Fullsend provides a base set; adopting organizations extend it via their `.fullsend` repository.
 See [architecture.md](architecture.md).
 
 ### Agent Runtime
@@ -62,7 +62,7 @@ A workflow concept where a repository automatically stays up-to-date with depend
 
 ### Flapping
 
-When agents enter a cycle of conflicting feedback that prevents convergence. Example: the security review agent rejects what the implementation agent produces to satisfy the correctness review agent, and vice versa, creating an oscillating loop. Flapping is a primary trigger for [escalation](#escalation) — after a configurable number of cycles, the system stops and routes to humans.
+When agents enter a cycle of conflicting feedback that prevents convergence. Example: the security review agent rejects what the code agent produces to satisfy the correctness review agent, and vice versa, creating an oscillating loop. Flapping is a primary trigger for [escalation](#escalation) — after a configurable number of cycles, the system stops and routes to humans.
 See [autonomy-spectrum.md](problems/autonomy-spectrum.md).
 
 ## H
@@ -83,7 +83,7 @@ See [architecture.md](architecture.md) and [agent-architecture.md](problems/agen
 
 ### Label State Machine
 
-The set of valid label transitions on issues and PRs that encode workflow state. Labels like `ready-to-implement`, `ready-for-review`, `ready-for-merge`, and `requires-manual-review` are control markers that drive agent dispatch and enforce ordering. The label state machine guard validates that transitions are legal and enforces mutual exclusion — for example, starting a triage run clears downstream labels so stale state does not carry forward.
+The set of valid label transitions on issues and PRs that encode workflow state. Labels like `ready-to-code`, `ready-for-review`, `ready-for-merge`, and `requires-manual-review` are control markers that drive agent dispatch and enforce ordering. The label state machine guard validates that transitions are legal and enforces mutual exclusion — for example, starting a triage run clears downstream labels so stale state does not carry forward.
 See [ADR 0002](ADRs/0002-initial-fullsend-design.md) building block 3.
 
 ## M
@@ -114,9 +114,9 @@ See [architecture.md](architecture.md) and [governance.md](problems/governance.m
 
 ## R
 
-### Ready to Implement
+### Ready to Code
 
-A label indicating an issue has passed triage and is cleared for the implementation agent to begin work. It is a key transition point in the [label state machine](#label-state-machine) — the triage agent sets it after confirming the issue is not a duplicate, is reproducible (if applicable), is a bug (not a feature, unless features are in scope), and has sufficient detail for implementation. The implementation agent watches for this label as its trigger to begin work.
+A label indicating an issue has passed triage and is cleared for the code agent to begin work. It is a key transition point in the [label state machine](#label-state-machine) — the triage agent sets it after confirming the issue is not a duplicate, is reproducible (if applicable), is a bug (not a feature, unless features are in scope), and has sufficient detail for the code agent. The code agent watches for this label as its trigger to begin work.
 See [ADR 0002](ADRs/0002-initial-fullsend-design.md).
 
 ### Rework Rate
@@ -142,7 +142,7 @@ See [architecture.md](architecture.md) and [codebase-context.md](problems/codeba
 
 ### Stage
 
-A higher-level workflow component in the fullsend pipeline (e.g., triage, implementation, review). The team formally chose "stage" over "phase" to avoid overloading the general SDLC use of "phase" and to maintain distinct vocabulary from Tekton's pipeline/task/step hierarchy, since fullsend may run on Tekton infrastructure. Each stage contains one or more [steps](#step).
+A higher-level workflow component in the fullsend pipeline (e.g., triage, code, review). The team formally chose "stage" over "phase" to avoid overloading the general SDLC use of "phase" and to maintain distinct vocabulary from Tekton's pipeline/task/step hierarchy, since fullsend may run on Tekton infrastructure. Each stage contains one or more [steps](#step).
 See [ADR 0002](ADRs/0002-initial-fullsend-design.md).
 
 ### Step
@@ -152,7 +152,7 @@ See [ADR 0002](ADRs/0002-initial-fullsend-design.md).
 
 ### Slash Command
 
-A GitHub comment in the form `/triage`, `/implement`, `/review`, etc., that manually triggers an agent workflow. Slash commands are parsed by the entry point and gated by an ACL — not every user can invoke every command. They provide an explicit human-initiated trigger alongside the automatic label-based triggers.
+A GitHub comment in the form `/triage`, `/code`, `/review`, etc., that manually triggers an agent workflow. Slash commands are parsed by the entry point and gated by an ACL — not every user can invoke every command. They provide an explicit human-initiated trigger alongside the automatic label-based triggers.
 See [ADR 0002](ADRs/0002-initial-fullsend-design.md) building block 2.
 
 ## T
@@ -164,7 +164,7 @@ See [architecture.md](architecture.md) (building block 1).
 
 ### Triage
 
-In fullsend, triage means routing, deduplicating, assessing completeness, and checking reproducibility — **not** fixing. The triage agent reads the issue, determines if it is a duplicate, assesses whether it is a bug or a feature (and denies if features are not in scope), checks if the issue has enough detail for implementation, and optionally attempts reproduction. The scope of triage has been a recurring discussion point, particularly around whether reproducibility and test generation belong in triage or implementation.
+In fullsend, triage means routing, deduplicating, assessing completeness, and checking reproducibility — **not** fixing. The triage agent reads the issue, determines if it is a duplicate, assesses whether it is a bug or a feature (and denies if features are not in scope), checks if the issue has enough detail for the code agent, and optionally attempts reproduction. The scope of triage has been a recurring discussion point, particularly around whether reproducibility and test generation belong in triage or implementation.
 See [ADR 0002](ADRs/0002-initial-fullsend-design.md) building block 4 and [#86](https://github.com/fullsend-ai/fullsend/issues/86).
 
 ### Trust
@@ -182,12 +182,12 @@ See [security-threat-model.md](problems/security-threat-model.md) and [agent-arc
 
 ### Work Coordinator
 
-The mechanism that assigns work to agents and prevents conflicts. The existing design principle is that the **repo is the coordinator** — branch protection, CODEOWNERS, status checks, and GitHub events provide coordination without a central orchestrator. The work coordinator may be just the glue connecting GitHub webhooks to agent infrastructure, or it may need to be more (e.g., a claim/lock system to prevent two implementation agents from picking up the same issue).
+The mechanism that assigns work to agents and prevents conflicts. The existing design principle is that the **repo is the coordinator** — branch protection, CODEOWNERS, status checks, and GitHub events provide coordination without a central orchestrator. The work coordinator may be just the glue connecting GitHub webhooks to agent infrastructure, or it may need to be more (e.g., a claim/lock system to prevent two code agents from picking up the same issue).
 See [architecture.md](architecture.md) and [#77](https://github.com/fullsend-ai/fullsend/issues/77).
 
 ## Z
 
 ### Zero Trust
 
-In fullsend's agent-to-agent model, zero trust means **nothing is trusted implicitly based on identity alone**. It does **not** mean "accept zero inputs" or "block everything." Every agent assumes every other agent — and every external input — could be compromised. The implementation agent assumes the triage output may contain prompt injection. The review agent assumes the submitted PR is designed to trick it. Defense is layered: input sanitization, scoped permissions, sandbox containment, and output validation all work together.
+In fullsend's agent-to-agent model, zero trust means **nothing is trusted implicitly based on identity alone**. It does **not** mean "accept zero inputs" or "block everything." Every agent assumes every other agent — and every external input — could be compromised. The code agent assumes the triage output may contain prompt injection. The review agent assumes the submitted PR is designed to trick it. Defense is layered: input sanitization, scoped permissions, sandbox containment, and output validation all work together.
 See [security-threat-model.md](problems/security-threat-model.md) (Threat 5) and [#102](https://github.com/fullsend-ai/fullsend/issues/102).

docs/landscape.md

@@ -51,7 +51,7 @@ Takes a fundamentally different angle: stacked PRs. Instead of reviewing one mas
 
 **Merge queue:** Stack-aware merge queue batches and tests multiple PRs in parallel. "Merge when ready" auto-pilots stack merges once approved — but approval is still human.
 
-**Relevance to fullsend:** The stacked PR insight is important for our implementation agents. Smaller, focused changes are easier for review sub-agents to evaluate with confidence. If implementation agents produce stacked PRs rather than monolithic ones, the review problem becomes more tractable. The merge queue concept is also relevant — our system needs something similar for sequencing autonomous merges.
+**Relevance to fullsend:** The stacked PR insight is important for our code agents. Smaller, focused changes are easier for review sub-agents to evaluate with confidence. If code agents produce stacked PRs rather than monolithic ones, the review problem becomes more tractable. The merge queue concept is also relevant — our system needs something similar for sequencing autonomous merges.
 
 ### Qodo (formerly PR-Agent)
 
@@ -103,7 +103,7 @@ Launched November 2025. The closest thing in the industry to autonomous merging.
 
 ## Production agent orchestration systems
 
-While the tools above focus on code review, a separate category of systems addresses end-to-end agent orchestration — from task intake through implementation and merge. These are closer to the fullsend vision than review-only tools.
+While the tools above focus on code review, a separate category of systems addresses end-to-end agent orchestration — from task intake through coding and merge. These are closer to the fullsend vision than review-only tools.
 
 ### Stripe Minions