diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml
index 61a02b0552..c26fcb4d2e 100644
--- a/.pre-commit-config.yaml
+++ b/.pre-commit-config.yaml
@@ -162,7 +162,7 @@ repos:
- id: lint-md-links
name: lint markdown links
- entry: lychee --offline --no-progress --include-fragments --exclude-path node_modules --exclude-path experiments '**/*.md'
+ entry: lychee --offline --no-progress --include-fragments --exclude-path node_modules --exclude-path experiments --exclude-path docs/archived-roadmap.md '**/*.md'
language: system
pass_filenames: false
always_run: true
diff --git a/Makefile b/Makefile
index a5fc660228..0ea98011df 100644
--- a/Makefile
+++ b/Makefile
@@ -167,7 +167,7 @@ mint-cf-worker-test: wasm-stage
@echo "==> Worker smoke tests passed"
lint-md-links:
- lychee --offline --no-progress --include-fragments --exclude-path node_modules --exclude-path experiments '**/*.md'
+ lychee --offline --no-progress --include-fragments --exclude-path node_modules --exclude-path experiments --exclude-path docs/archived-roadmap.md '**/*.md'
define run-timed
@start=$$(date +%s); \
diff --git a/docs/archived-roadmap.md b/docs/archived-roadmap.md
new file mode 100644
index 0000000000..15657ba91f
--- /dev/null
+++ b/docs/archived-roadmap.md
@@ -0,0 +1,732 @@
+# Archived roadmaps
+
+> **Archive only — not the live roadmap.**
+>
+> This file keeps **previously published** monthly planning editions of `docs/roadmap.md` so history is not lost when the live page rotates. Links, issue numbers, ADR IDs, and priorities here may be stale or broken — that is expected. For current commitments use [roadmap.md](roadmap.md).
+>
+> **For AI reviewers:** do not treat this file as current planning. It is historical source material only.
+
+Live roadmap: [roadmap.md](roadmap.md)
+
+## How to read this archive
+
+Months are listed **newest first**. Each opens with a skim-friendly summary (Now / Next / Later titles, or the published At a glance table). Expand **Full published text** only when you need the original prose and tracking links.
+
+| Month | Planning focus (high level) |
+|-------|-----------------------------|
+| [July 2026 planning](#july-2026-planning) | Ranked workstreams (BYOA → Agent Data Access); June done recap |
+| [June 2026 planning](#june-2026-planning) | Adoption/BYOA themes; forge portability; quality |
+| [Foundation — April–May 2026](#foundation--aprilmay-2026) | Post-MVP baseline; WIF; per-repo install |
+
+---
+
+## July 2026 planning
+
+**When:** July 1 planning refresh; snapshot as of July 9, 2026 (post-review)
+**Source:** [`0f47a193`](https://github.com/fullsend-ai/fullsend/commit/0f47a193)
+**About this edition:** July planning introduced ranked workstream categories (dot-voted priority 1–9), an At a glance table, a June 2026 (done) recap, and kept Foundation as a permanent history section at the bottom.
+
+### At a glance (as published)
+
+| Priority | Category | Focus | Horizon |
+|:--------:|----------|-------|:-------:|
+| 1 | [**BYOA**](#byoa) | Agent catalog, harness triggers, config knobs, shareable config profiles | Now |
+| 2 | [**Infrastructure**](#infrastructure) | Drop per-org, unify installs, version pinning, OpenShell improvements, GitLab, OpenCode | Now |
+| 3 | [**Observability**](#observability) | Cost measurement, telemetry phase 2 & 3, surfacing hidden agent failures | Now |
+| 4 | [**Testing**](#testing) | Behavior tests for deterministic code, functional tests for all agents, evals, stage tests | Now |
+| 5 | [**External Partnerships**](#external-partnerships) | OpenShell/Ansible/TektonCD using fullsend, community building, docs improvements | Now |
+| 6 | [**JIRA**](#jira) | JIRA support for all default agents, mint for JIRA | Now |
+| 7 | [**mint**](#mint) | Extract mint repo, finish public mint, e2e tests, move to prod GCP project | Now |
+| 8 | [**Agent Data Access**](#agent-data-access) | Data connectors (JIRA, GitLab, Slack), multi-repo context, agent environment planning | Now |
+| 9 | [**Exploration**](#exploration) | Persistent agent memories, auto-merge (tiny percentage) | Next |
+| — | [Cross-forge orchestration](#cross-forge-orchestration) | Coordinating agent work across GitHub + GitLab orgs | Next |
+| — | [Kubernetes and OpenShift execution](#kubernetes-and-openshift-execution) | K8s/OpenShift as agent runtime | Later |
+| — | [Security hardening](#security-hardening) | Prompt injection defense, credential isolation, threat model | Later |
+| — | [Human factors and governance](#human-factors-and-governance) | Domain ownership, review fatigue, contributor motivation | Later |
+| — | [Production feedback loops](#production-feedback-loops) | Production signals driving triage and prioritization | Later |
+| — | [Agent attestations](#agent-attestations) | Cryptographic provenance for agent output | Later |
+
+### Also on this edition
+
+- **June 2026 (done)** — June focused on platform architecture maturation, harness portability, review agent reliability, and developer experience. Over 90 PRs merged and 150+ issues closed.
+- **Foundation (April–May 2026)** — Fullsend reached MVP in April 2026 and scaled through May. The platform can be installed at the org level, enroll repositories, and run a full autonomous SDLC loop: triage issues, produce code and tes…
+
+
+Full published text — July 2026 planning (click to expand)
+
+Where fullsend is, and where it is going. Organized as **Now / Next / Later** — what we are actively building, what follows immediately after, and what we see on the horizon.
+
+Categories are listed in the priority order established at the [July 1 planning session](#now). The ordering reflects team dot-voting decisions.
+
+**At a glance**
+
+
+| Priority | Category | Focus | Horizon |
+|:--------:|----------|-------|:-------:|
+| 1 | [**BYOA**](#byoa) | Agent catalog, harness triggers, config knobs, shareable config profiles | Now |
+| 2 | [**Infrastructure**](#infrastructure) | Drop per-org, unify installs, version pinning, OpenShell improvements, GitLab, OpenCode | Now |
+| 3 | [**Observability**](#observability) | Cost measurement, telemetry phase 2 & 3, surfacing hidden agent failures | Now |
+| 4 | [**Testing**](#testing) | Behavior tests for deterministic code, functional tests for all agents, evals, stage tests | Now |
+| 5 | [**External Partnerships**](#external-partnerships) | OpenShell/Ansible/TektonCD using fullsend, community building, docs improvements | Now |
+| 6 | [**JIRA**](#jira) | JIRA support for all default agents, mint for JIRA | Now |
+| 7 | [**mint**](#mint) | Extract mint repo, finish public mint, e2e tests, move to prod GCP project | Now |
+| 8 | [**Agent Data Access**](#agent-data-access) | Data connectors (JIRA, GitLab, Slack), multi-repo context, agent environment planning | Now |
+| 9 | [**Exploration**](#exploration) | Persistent agent memories, auto-merge (tiny percentage) | Next |
+| — | [Cross-forge orchestration](#cross-forge-orchestration) | Coordinating agent work across GitHub + GitLab orgs | Next |
+| — | [Kubernetes and OpenShift execution](#kubernetes-and-openshift-execution) | K8s/OpenShift as agent runtime | Later |
+| — | [Security hardening](#security-hardening) | Prompt injection defense, credential isolation, threat model | Later |
+| — | [Human factors and governance](#human-factors-and-governance) | Domain ownership, review fatigue, contributor motivation | Later |
+| — | [Production feedback loops](#production-feedback-loops) | Production signals driving triage and prioritization | Later |
+| — | [Agent attestations](#agent-attestations) | Cryptographic provenance for agent output | Later |
+
+**June 2026 (done)**
+
+
+June focused on platform architecture maturation, harness portability, review agent reliability, and developer experience. Over 90 PRs merged and 150+ issues closed.
+
+What this phase delivered:
+
+- **Agent registration and BYOA foundations** — ADR 0058 landed in three phases: agent registration schema, `fullsend agent` CLI subcommand, and runtime agent resolution from config ([#2768](https://github.com/fullsend-ai/fullsend/pull/2768), [#2769](https://github.com/fullsend-ai/fullsend/pull/2769), [#2770](https://github.com/fullsend-ai/fullsend/pull/2770))
+- **Unified env var delivery** — ADR 0055 unified runner and sandbox environment variable delivery, with all default agents migrated to the new `env.runner`/`env.sandbox` schema ([#2582](https://github.com/fullsend-ai/fullsend/pull/2582), [#2763](https://github.com/fullsend-ai/fullsend/pull/2763), [#2762](https://github.com/fullsend-ai/fullsend/pull/2762), [#2759](https://github.com/fullsend-ai/fullsend/pull/2759))
+- **PR-based scaffold delivery** — install now defaults to creating PRs instead of pushing directly to the default branch, with `--direct` flag for the old behavior and fork support for non-owner users ([#2533](https://github.com/fullsend-ai/fullsend/pull/2533), [#2630](https://github.com/fullsend-ai/fullsend/pull/2630))
+- **Docs site migration** — migrated from Docusaurus to VitePress with a redesigned landing page, mermaid diagram rendering, and sidebar ordering control ([#2721](https://github.com/fullsend-ai/fullsend/pull/2721), [#2701](https://github.com/fullsend-ai/fullsend/pull/2701), [#2754](https://github.com/fullsend-ai/fullsend/pull/2754))
+- **Dispatch hardening** — label-based gating for agent dispatch (ADR 0054), retro dispatch skip guards for bot dependency PRs, and rate-limit retry improvements ([#2679](https://github.com/fullsend-ai/fullsend/pull/2679), [#2764](https://github.com/fullsend-ai/fullsend/pull/2764))
+- **Review agent reliability** — review sub-agent depth scaling, challenger pass dedicated sub-agent, line-number verification, finding deduplication, and severity-aligned verdicts ([#2695](https://github.com/fullsend-ai/fullsend/pull/2695))
+- **OpenShell tracking** — tracked OpenShell through versions 0.0.38 to 0.0.72, resolving sandbox boundary checks, nftables requirements, JWT auth conflicts, and supervisor image pinning ([#1763](https://github.com/fullsend-ai/fullsend/issues/1763), [#1764](https://github.com/fullsend-ai/fullsend/issues/1764), [#1765](https://github.com/fullsend-ai/fullsend/issues/1765), [#1766](https://github.com/fullsend-ai/fullsend/issues/1766), [#1768](https://github.com/fullsend-ai/fullsend/issues/1768))
+- **Renovate enablement** — self-hosted Renovate GitHub App with automerge for low-risk dependency PRs ([#2480](https://github.com/fullsend-ai/fullsend/pull/2480), [#2546](https://github.com/fullsend-ai/fullsend/pull/2546))
+- **Agent status comments** — agents now post status comments on workflow start and completion, with timeline analysis and token-expiry resilience ([#1859](https://github.com/fullsend-ai/fullsend/issues/1859))
+- **Security hardening** — all GitHub Actions pinned to full-length commit SHAs, DCO enforcement, SRI attributes on CDN scripts ([#2508](https://github.com/fullsend-ai/fullsend/pull/2508), [#2509](https://github.com/fullsend-ai/fullsend/pull/2509))
+- **E2e expansion** — org pool expanded from 6 to 12, fork PR support, functional test gates with collaborator permission fallback ([#2766](https://github.com/fullsend-ai/fullsend/pull/2766))
+- **Standalone runtime progress** — standalone mint with custom role support shipped ([#2537](https://github.com/fullsend-ai/fullsend/pull/2537)), default `--mint-url` now points to hosted public mint removing GCP provisioning requirement ([#2073](https://github.com/fullsend-ai/fullsend/issues/2073)), `fullsend run` wired with Lint diagnostics and `LoadWithBase` pipelines ([#2362](https://github.com/fullsend-ai/fullsend/pull/2362), [#2224](https://github.com/fullsend-ai/fullsend/pull/2224)), and `--vendor` flag for self-contained workflow assets ([#2145](https://github.com/fullsend-ai/fullsend/issues/2145))
+- **Harness CEL dispatch** — ADR for harness-level CEL dispatch and NormalizedEvent v1 landed ([#2650](https://github.com/fullsend-ai/fullsend/pull/2650))
+- **URL-based harness composition** — resolved scripts, skills, and declarative resources from URL-referenced base harnesses ([#2525](https://github.com/fullsend-ai/fullsend/pull/2525), [#2690](https://github.com/fullsend-ai/fullsend/pull/2690), [#2707](https://github.com/fullsend-ai/fullsend/pull/2707))
+
+**Now**
+
+
+What we are actively building and shipping. Categories are ordered by priority from the July 2026 planning session.
+
+**BYOA**
+
+
+Making fullsend a platform teams can adopt incrementally and extend freely. This is the team's highest priority for July — driven by user demand for custom agents, better configuration, and simplified adoption.
+
+The custom agent interface needs to be clean enough that replatforming an existing agent is straightforward, not a rewrite. Easy local agent runs let users test-drive custom agents and skills before wiring them into CI. An agent catalog (an "awesome list" style repository for discovering and sharing agent definitions) will make the ecosystem more visible and navigable. Shareable config profiles let teams preconfigure a deployment with a single URL. Scribe agent enhancements address multiple outstanding user requests and will move to the agents repo as part of the re-platforming effort.
+
+Examples of work that could move this forward:
+
+- Harness triggers and dynamic agent dispatching ([#2565](https://github.com/fullsend-ai/fullsend/issues/2565))
+- Major config knobs for agents — making agents more adaptable to user preferences ([#2832](https://github.com/fullsend-ai/fullsend/issues/2832))
+- Scribe agent enhancements and migration to agents repo ([#895](https://github.com/fullsend-ai/fullsend/issues/895), [#222](https://github.com/fullsend-ai/fullsend/issues/222), [#1674](https://github.com/fullsend-ai/fullsend/issues/1674))
+- Re-platform default agents as harness-driven configs ([#1986](https://github.com/fullsend-ai/fullsend/issues/1986), [#1985](https://github.com/fullsend-ai/fullsend/issues/1985))
+- Harness definition architecture and config schema ([#173](https://github.com/fullsend-ai/fullsend/issues/173), [#179](https://github.com/fullsend-ai/fullsend/issues/179), [#235](https://github.com/fullsend-ai/fullsend/issues/235))
+- Skills loading policy and org/repo inheritance ([#237](https://github.com/fullsend-ai/fullsend/issues/237), [#236](https://github.com/fullsend-ai/fullsend/issues/236))
+- Selective agent enablement in config ([#581](https://github.com/fullsend-ai/fullsend/issues/581), [#604](https://github.com/fullsend-ai/fullsend/issues/604))
+- Authorization model for agent invocations ([#1662](https://github.com/fullsend-ai/fullsend/issues/1662), [#1687](https://github.com/fullsend-ai/fullsend/issues/1687))
+- Provider and profile resolution from URL-referenced bases ([#2672](https://github.com/fullsend-ai/fullsend/issues/2672))
+- Easy local agent runs — test drive custom agents and skills locally ([#1963](https://github.com/fullsend-ai/fullsend/issues/1963), [#595](https://github.com/fullsend-ai/fullsend/issues/595))
+
+**Infrastructure**
+
+
+Platform infrastructure, technical debt reduction, and runtime improvements. This category consolidates what was previously split across "Agent Capabilities & Runtime", "Upgrades & Versioning", and "New Forges" from the June plan — the team recognized these share enough infrastructure overlap to manage together.
+
+Key themes: deprecating per-org installs in favor of a unified approach, version pinning and automatic upgrades, OpenShell improvements (Go SDK migration, API extensibility, Vertex API authorization fixes), running agents outside GitHub Actions (GitLab, Tekton infrastructure), and OpenCode alignment with the global engineering working group.
+
+Examples of work that could move this forward:
+
+- Drop per-org installs — deprecate and remove in favor of unified install ([#2454](https://github.com/fullsend-ai/fullsend/issues/2454), [#2302](https://github.com/fullsend-ai/fullsend/issues/2302))
+- Version pinning and automatic upgrades ([#1933](https://github.com/fullsend-ai/fullsend/issues/1933), [#2454](https://github.com/fullsend-ai/fullsend/issues/2454))
+- OpenShell improvements — simplification, Go SDK migration, API extensibility, Vertex authorization fixes ([#2692](https://github.com/fullsend-ai/fullsend/issues/2692))
+- GitLab support — webhook bridge, GitLab CI as trigger/coordination layer ([#1964](https://github.com/fullsend-ai/fullsend/issues/1964))
+- Forge-portable harness schema ([#1605](https://github.com/fullsend-ai/fullsend/issues/1605))
+- OpenCode alignment with global engineering working group ([#1260](https://github.com/fullsend-ai/fullsend/issues/1260), [#1935](https://github.com/fullsend-ai/fullsend/issues/1935))
+- Refactor runAgent for testability ([#2831](https://github.com/fullsend-ai/fullsend/issues/2831))
+
+**Observability**
+
+
+Understanding what agents cost, how they perform, and where they silently fail. This is a new category for July — elevated because users are increasingly asking for visibility into agent behavior and costs.
+
+A key problem surfaced in the planning session: agents can silently repeat the same mistakes across separate runs with no mechanism to surface previous failures. Cost measurement and aggregation will help teams understand their agent usage. Telemetry phase 2 & 3 build on existing tracing foundations to provide deeper operational insight.
+
+Examples of work that could move this forward:
+
+- Cost measurement and aggregation — per-repo and per-agent token/cost tracking ([#2668](https://github.com/fullsend-ai/fullsend/issues/2668))
+- Telemetry phase 2 & 3 — OpenTelemetry Go SDK for trace export ([#2780](https://github.com/fullsend-ai/fullsend/issues/2780)), trace chain integrity ([#2779](https://github.com/fullsend-ai/fullsend/issues/2779))
+- Agent error visibility — handling `is_error:true` responses from runtimes ([#2786](https://github.com/fullsend-ai/fullsend/issues/2786))
+- OIDC token staleness when sandbox setup exceeds timeout ([#2783](https://github.com/fullsend-ai/fullsend/issues/2783))
+- Release summary bot for automated changelog visibility ([#2778](https://github.com/fullsend-ai/fullsend/issues/2778))
+
+**Testing**
+
+
+How we gain confidence in what we ship. Building comprehensive testing infrastructure across behavioral tests, functional tests, evaluation frameworks, and staging environments.
+
+The team identified a gap between how e2e tests work (vendored files, per-commit tricks) and how users actually use fullsend. Stage tests running post-merge in a staging environment will close this gap and provide more realistic validation.
+
+Examples of work that could move this forward:
+
+- Behavior tests for deterministic code paths — tests that validate without running LLMs ([#346](https://github.com/fullsend-ai/fullsend/issues/346))
+- Evaluation frameworks — SWE-bench pilot, Harbor for code-agent outcome eval ([#2510](https://github.com/fullsend-ai/fullsend/issues/2510))
+- Statistical significance layer for non-deterministic evals ([#2460](https://github.com/fullsend-ai/fullsend/issues/2460))
+- E2e test improvements — bot authorization fixes, auth alignment ([#2641](https://github.com/fullsend-ai/fullsend/issues/2641), [#2772](https://github.com/fullsend-ai/fullsend/issues/2772), [#2489](https://github.com/fullsend-ai/fullsend/issues/2489))
+- Trustworthiness evidence — rework rate tracking, review outcome analysis ([#295](https://github.com/fullsend-ai/fullsend/issues/295))
+
+**External Partnerships**
+
+
+Making fullsend visible, understandable, and usable by teams outside the core group. This category combines documentation improvements with active partnership engagement — recognizing that docs quality and external adoption are tightly linked.
+
+Multiple teams are actively using or evaluating fullsend: OpenShell, Ansible, TektonCD, and potential enterprise partnerships. The Tekton CI team is hitting GitHub Actions resource limits, making non-GHA execution an increasingly relevant concern. Documentation improvements are a direct response to user feedback — people are adopting fullsend but struggling with the docs. The team plans to schedule screen-share sessions with users to observe how they interpret documentation and identify friction points.
+
+Examples of work that could move this forward:
+
+- Docs site experiments content and public mint docs ([#2757](https://github.com/fullsend-ai/fullsend/issues/2757))
+- Document maintainer onboarding process ([#2653](https://github.com/fullsend-ai/fullsend/issues/2653))
+- JIRA data leakage risk documentation for public repos ([#2513](https://github.com/fullsend-ai/fullsend/issues/2513))
+
+**JIRA**
+
+
+Connecting fullsend to JIRA — extending the trigger model beyond forge events into project management. This is focused specifically on making fullsend agents work with JIRA data and workflows.
+
+The scope covers JIRA support across all default agents (not just triage), credential management for JIRA service accounts, and the possibility of a dedicated mint for JIRA using Workload Identity Federation. The plan is to start with public JIRA projects to avoid private data exposure.
+
+Examples of work that could move this forward:
+
+- JIRA support for all default agents — triage ([#2264](https://github.com/fullsend-ai/fullsend/issues/2264)), code ([#2265](https://github.com/fullsend-ai/fullsend/issues/2265)), prioritize ([#2266](https://github.com/fullsend-ai/fullsend/issues/2266)), retro ([#2267](https://github.com/fullsend-ai/fullsend/issues/2267)), review ([#2268](https://github.com/fullsend-ai/fullsend/issues/2268)), refine ([#1341](https://github.com/fullsend-ai/fullsend/issues/1341))
+- JIRA trigger model ([#2263](https://github.com/fullsend-ai/fullsend/issues/2263))
+- Mint for JIRA — Workload Identity Federation for JIRA service accounts ([#2269](https://github.com/fullsend-ai/fullsend/issues/2269))
+
+Related: [downstream-upstream](problems/downstream-upstream.md), [intent-representation](problems/intent-representation.md)
+
+**mint**
+
+
+Extracting, hardening, and operationalizing the token mint as a standalone service. The mint is already fairly standalone in the codebase — this work completes the separation, adds proper test coverage, and moves it to production infrastructure. Longer-term goals include extracting the mint into its own repository and migrating mint infrastructure to a dedicated GCP project separate from dev/inference.
+
+Examples of work that could move this forward:
+
+- Finish public mint work — implementing ADR 0059 public mint mode ([#2773](https://github.com/fullsend-ai/fullsend/pull/2773), [#2073](https://github.com/fullsend-ai/fullsend/issues/2073))
+- mint delete command for infrastructure teardown ([#2680](https://github.com/fullsend-ai/fullsend/issues/2680))
+- Token caching with safe refresh across nested CLI invocations ([#2542](https://github.com/fullsend-ai/fullsend/issues/2542))
+- Consolidate agent role lists and permission definitions ([#2449](https://github.com/fullsend-ai/fullsend/issues/2449))
+- Evaluate database-backed persistence for mint identity ([#2564](https://github.com/fullsend-ai/fullsend/issues/2564))
+- Mint service decomposition criteria ([#2437](https://github.com/fullsend-ai/fullsend/issues/2437))
+- Deployment suggestions and health check capabilities ([#2438](https://github.com/fullsend-ai/fullsend/issues/2438))
+
+**Agent Data Access**
+
+
+Giving agents access to data beyond the repository — JIRA, GitLab, Slack, Google Drive, and multi-repo context. This is distinct from the JIRA category (which focuses on JIRA-specific workflows) and addresses the broader challenge of connecting agents to external data sources securely.
+
+The team recognized this requires more than just adding skills: it involves credential management, network policies, service accounts, and context-aware loading for data sources like JIRA, GitLab, Slack, and Google Drive. ADRs are needed before implementation to establish patterns rather than accumulating ad-hoc integrations.
+
+Examples of work that could move this forward:
+
+- Multi-repo context loading and cross-repo changes ([#298](https://github.com/fullsend-ai/fullsend/issues/298), [#401](https://github.com/fullsend-ai/fullsend/issues/401), [#1276](https://github.com/fullsend-ai/fullsend/issues/1276))
+- Secretless deployment and credential management strategies ([#1952](https://github.com/fullsend-ai/fullsend/issues/1952), [#1604](https://github.com/fullsend-ai/fullsend/issues/1604))
+- Least-privilege path for workflow file changes ([#2822](https://github.com/fullsend-ai/fullsend/issues/2822))
+- Human-gated permission adjustments ([#2821](https://github.com/fullsend-ai/fullsend/issues/2821), [#2829](https://github.com/fullsend-ai/fullsend/issues/2829))
+
+**Next**
+
+
+What follows once the current work stabilizes.
+
+**Exploration**
+
+
+Ideas the team is actively thinking about but not yet committed to building. These received no votes in the July planning session but are tracked for future consideration.
+
+- **Persistent agent memories** — agents retain context and history across sessions, enabling learning from past mistakes. The team agreed this must be traceable and transparent to humans — hidden memory is rejected. Security concerns around persistent threats through memory injection need resolution before this moves forward.
+- **Auto-merge (tiny percentage)** — beginning to reason about where auto-merge is safe, starting with a very small percentage of changes where trustworthiness evidence supports it. Related: [autonomy-spectrum](problems/autonomy-spectrum.md), [code-review](problems/code-review.md), ADR 0062 ([#2791](https://github.com/fullsend-ai/fullsend/pull/2791))
+
+**Cross-forge orchestration**
+
+
+Coordinating agent work across multiple forges (GitHub + GitLab, or multiple GitHub orgs) when a single logical change spans organizational boundaries.
+
+**Later**
+
+
+Problems we are actively thinking about but not yet building. These are informed by the [problem documents](problems/) and will move into **Next** as the platform matures.
+
+**Kubernetes and OpenShift execution**
+
+
+When the sandbox runtime matures to run practically in Kubernetes and OpenShift, fullsend should support that as an execution environment. This also opens the door to triggering agent workflows from sources beyond GitHub and GitLab — decoupling the agent runtime from the forge.
+
+**Security hardening**
+
+
+Ongoing work informed by the [security threat model](problems/security-threat-model.md):
+
+- Prompt injection detection and andon cord ([#172](https://github.com/fullsend-ai/fullsend/issues/172), [#174](https://github.com/fullsend-ai/fullsend/issues/174))
+- Org guardrail protection ([#84](https://github.com/fullsend-ai/fullsend/issues/84))
+- Workflow security scanning ([#159](https://github.com/fullsend-ai/fullsend/issues/159))
+- Agent authority modeling ([#877](https://github.com/fullsend-ai/fullsend/issues/877))
+- Separate permission profiles per run phase ([#2826](https://github.com/fullsend-ai/fullsend/issues/2826))
+- Privileged operations only in deterministic automation ([#2828](https://github.com/fullsend-ai/fullsend/issues/2828))
+
+**Human factors and governance**
+
+
+As autonomous contribution scales, the organizational questions become unavoidable: domain ownership shifts, review fatigue, contributor motivation, and who has authority to make binding decisions about agent behavior.
+
+- Related: [human-factors](problems/human-factors.md), [governance](problems/governance.md), [contribution-volume](problems/contribution-volume.md)
+
+**Production feedback loops**
+
+
+Closing the loop between production signals and what agents work on next. Platform organizations generate structured execution data that can drive triage and prioritization without waiting for humans to notice failures.
+
+- Related: [production-feedback](problems/production-feedback.md)
+
+**Agent attestations**
+
+
+Cryptographic attestation of agent-produced artifacts, enabling consumers to verify what agent produced a change, under what policy, and with what inputs.
+
+- See [#267](https://github.com/fullsend-ai/fullsend/issues/267)
+
+**Foundation (April–May 2026)**
+
+
+Fullsend reached MVP in April 2026 and scaled through May. The platform can be installed at the org level, enroll repositories, and run a full autonomous SDLC loop: triage issues, produce code and tests, review PRs, apply fixes from review feedback, and file retrospective improvement proposals. The core agent suite ships as **default agents** and is designed to be general, extensible, and replaceable.
+
+What this phase established:
+
+- **Sandboxed runner architecture** — agents execute in isolated environments with controlled access to forge credentials and repository content
+- **Default agent suite** — default agents that enable an end-to-end bugfix workflow: triage, code, review, fix, and retro
+- **Binary autonomy model** — per-repo opt-in, CODEOWNERS enforcing human approval on protected paths
+- **The repo is the coordinator** — branch protection, CODEOWNERS, and status checks replace a coordinator agent
+- **Trust derives from repository permissions, not agent identity**
+- **Fullsend is using fullsend** — the platform dogfoods its own agent workflows
+- **20+ Konflux repositories** running fullsend for bug triage, code production, and review
+
+
+
+
+---
+
+## June 2026 planning
+
+**When:** Planning rewrite published June 9, 2026
+**Source:** [`36ac3a57`](https://github.com/fullsend-ai/fullsend/commit/36ac3a57)
+**About this edition:** June planning session roadmap. Organized by work themes under Now/Next/Later (prose sections — not yet the ranked priority table).
+
+> An earlier June 7 refresh (`124dec4a`) existed before this planning rewrite; the June 9 version is the one that reflected the planning session.
+
+### Now
+
+- Adoption and extensibility
+- Quality protections
+- Agent capabilities
+- Versioning and pinning
+- Forge portability
+- Feature refinement
+
+### Next
+
+- Trustworthiness evidence
+- Standalone local runtime
+- JIRA-driven workflows
+- Auto-merge readiness
+
+### Later
+
+- Kubernetes and OpenShift execution
+- Production feedback loops
+- Cross-forge orchestration
+- Security hardening
+- Human factors and governance
+- Agent attestations
+
+
+Full published text — June 2026 planning (click to expand)
+
+Where fullsend is, and where it is going. Organized as **Now / Next / Later** — what we are actively building, what follows immediately after, and what we see on the horizon.
+
+**Foundation (done)**
+
+
+Fullsend reached MVP in April 2026 and scaled through May. The platform can be installed at the org level, enroll repositories, and run a full autonomous SDLC loop: triage issues, produce code and tests, review PRs, apply fixes from review feedback, and file retrospective improvement proposals. The core agent suite ships as **OOTB (out-of-the-box) agents** and is designed to be general, extensible, and replaceable.
+
+What this phase established:
+
+- **Sandboxed runner architecture** — agents execute in isolated environments with controlled access to forge credentials and repository content
+- **Default agent suite** — OOTB agents that enable an end-to-end bugfix workflow: triage, code, review, fix, and retro
+- **Binary autonomy model** — per-repo opt-in, CODEOWNERS enforcing human approval on protected paths
+- **The repo is the coordinator** — branch protection, CODEOWNERS, and status checks replace a coordinator agent
+- **Trust derives from repository permissions, not agent identity**
+- **Fullsend is using fullsend** — the platform dogfoods its own agent workflows
+- **20+ Konflux repositories** running fullsend for bug triage, code production, and review
+
+**Now**
+
+
+What we are actively building and shipping.
+
+**Adoption and extensibility**
+
+
+Teams use fullsend as a platform — plugging in their own agents, skills, and orchestration while inheriting the platform's security model, sandbox isolation, and coordination layer. At the same time, teams adopt fullsend incrementally — enabling only the capabilities they want without committing to the full workflow or extensive infrastructure setup.
+
+The BYOA interface needs to be clean enough that replatforming an existing agent is straightforward, not a rewrite. Prospective users are requesting simplified onboarding, selective agent enablement, and a clear authorization model that prevents non-maintainers from triggering agent workloads without team approval.
+
+Examples of work that could move this forward:
+
+- Harness definition architecture and config schema ([#173](https://github.com/fullsend-ai/fullsend/issues/173), [#179](https://github.com/fullsend-ai/fullsend/issues/179), [#235](https://github.com/fullsend-ai/fullsend/issues/235))
+- Re-platform default agents as harness-driven configs ([#1986](https://github.com/fullsend-ai/fullsend/issues/1986), [#1985](https://github.com/fullsend-ai/fullsend/issues/1985))
+- Skills loading policy and org/repo inheritance ([#237](https://github.com/fullsend-ai/fullsend/issues/237), [#236](https://github.com/fullsend-ai/fullsend/issues/236))
+- Forge-portable harness schema ([#1605](https://github.com/fullsend-ai/fullsend/issues/1605), [#1848](https://github.com/fullsend-ai/fullsend/pull/1848))
+- Per-repo workflow definitions ([#69](https://github.com/fullsend-ai/fullsend/issues/69))
+- Secretless deployment via Workload Identity Federation ([#1952](https://github.com/fullsend-ai/fullsend/issues/1952), [#1604](https://github.com/fullsend-ai/fullsend/issues/1604))
+- Per-repo installation (adopting without org-wide configuration) ([#727](https://github.com/fullsend-ai/fullsend/issues/727), [#1954](https://github.com/fullsend-ai/fullsend/pull/1954))
+- Reducing infrastructure requirements during onboarding ([#1216](https://github.com/fullsend-ai/fullsend/issues/1216), [#1145](https://github.com/fullsend-ai/fullsend/issues/1145))
+- Selective agent enablement in config ([#581](https://github.com/fullsend-ai/fullsend/issues/581), [#604](https://github.com/fullsend-ai/fullsend/issues/604))
+- Authorization model for agent invocations ([#1662](https://github.com/fullsend-ai/fullsend/issues/1662), [#1687](https://github.com/fullsend-ai/fullsend/issues/1687))
+
+**Quality protections**
+
+
+Build up the testing, staging, and evaluation infrastructure that gives us confidence in what we ship. Evals, behavioral tests, functional tests, dedicated staging environments, and improved end-to-end coverage — making it harder for regressions to slip through and easier to verify that agents behave correctly.
+
+Examples of work that could move this forward:
+
+- Behavioral test suites with dummy runtimes ([#346](https://github.com/fullsend-ai/fullsend/issues/346), [#1982](https://github.com/fullsend-ai/fullsend/pull/1982))
+- Agent output evaluation frameworks ([#73](https://github.com/fullsend-ai/fullsend/issues/73), [#499](https://github.com/fullsend-ai/fullsend/issues/499), [#1682](https://github.com/fullsend-ai/fullsend/pull/1682))
+- Layered and standalone distribution modes for testability ([#1954](https://github.com/fullsend-ai/fullsend/pull/1954))
+- Expanded e2e coverage with authorization gate testing ([#1983](https://github.com/fullsend-ai/fullsend/pull/1983))
+- Static analysis layer for testing agents ([#1826](https://github.com/fullsend-ai/fullsend/pull/1826))
+
+**Agent capabilities**
+
+
+Improving what agents can do and the runtime they operate in. This covers cross-repo workflows, better context provisioning, onboarding reliability, runtime enhancements, and ongoing improvements to individual agents. Partnering with the OpenShell team to advance the agentic SDLC is part of this work.
+
+Examples of work that could move this forward:
+
+- Multi-repo context loading and cross-repo changes ([#298](https://github.com/fullsend-ai/fullsend/issues/298), [#401](https://github.com/fullsend-ai/fullsend/issues/401), [#1276](https://github.com/fullsend-ai/fullsend/issues/1276))
+- Better context for agents before coding ([#932](https://github.com/fullsend-ai/fullsend/issues/932), [#1255](https://github.com/fullsend-ai/fullsend/issues/1255), [#1200](https://github.com/fullsend-ai/fullsend/issues/1200))
+- Onboarding improvements and branch protection handling ([#1758](https://github.com/fullsend-ai/fullsend/issues/1758), [#1689](https://github.com/fullsend-ai/fullsend/issues/1689))
+- Public mint finalization ([#2073](https://github.com/fullsend-ai/fullsend/issues/2073), [#2071](https://github.com/fullsend-ai/fullsend/issues/2071), [#1145](https://github.com/fullsend-ai/fullsend/issues/1145))
+- OpenShell tracking and integration ([#773](https://github.com/fullsend-ai/fullsend/issues/773), [#1721](https://github.com/fullsend-ai/fullsend/issues/1721), [#1813](https://github.com/fullsend-ai/fullsend/issues/1813))
+- OpenCode as an alternative agent runtime ([#1260](https://github.com/fullsend-ai/fullsend/issues/1260), [#1935](https://github.com/fullsend-ai/fullsend/issues/1935), [#608](https://github.com/fullsend-ai/fullsend/issues/608))
+- Scribe agent enhancements ([#895](https://github.com/fullsend-ai/fullsend/issues/895), [#222](https://github.com/fullsend-ai/fullsend/issues/222), [#1674](https://github.com/fullsend-ai/fullsend/issues/1674))
+
+**Versioning and pinning**
+
+
+Define and implement a strategy for versioning workflows, agents, and dependencies so that releases are deterministic and upgradable. An ADR is in progress to evaluate options before implementation begins. Referring to resources by digest enables more deterministic pinning; agents may eventually move to separate repositories for independent versioning.
+
+Examples of work that could move this forward:
+
+- Pin workflows to the version being installed ([#1933](https://github.com/fullsend-ai/fullsend/issues/1933))
+- Schema versioning for harness definitions ([#235](https://github.com/fullsend-ai/fullsend/issues/235), [#179](https://github.com/fullsend-ai/fullsend/issues/179))
+- Renovate automation for dependency pins ([#773](https://github.com/fullsend-ai/fullsend/issues/773), [#544](https://github.com/fullsend-ai/fullsend/issues/544))
+- Plugin repository approach for independent agent versioning ([#631](https://github.com/fullsend-ai/fullsend/issues/631))
+- Build from source fallback when no published release exists ([#2026](https://github.com/fullsend-ai/fullsend/issues/2026))
+
+**Forge portability**
+
+
+GitHub is the starting point, not the boundary. GitLab support requires solving webhook-to-pipeline translation, MR-event security models, and forge interface abstraction. This work continues incrementally alongside higher-priority items.
+
+Related: [gitlab-implementation](problems/gitlab-implementation.md)
+
+Examples of work that could move this forward:
+
+- GitLab webhook bridge ([#1964](https://github.com/fullsend-ai/fullsend/issues/1964), [#1816](https://github.com/fullsend-ai/fullsend/pull/1816))
+- Forge-portable harness schema ([#1605](https://github.com/fullsend-ai/fullsend/issues/1605), [#1848](https://github.com/fullsend-ai/fullsend/pull/1848))
+
+**Feature refinement**
+
+
+Agents participate in feature definition — not just bugfixes. When ideas are filed, agents can autonomously produce feature definitions, ask clarifying questions, and prepare material for refinement ceremonies. Teams still own the definition; agents accelerate it. Community members are already exploring JIRA integration independently — we should engage them and build on their work rather than starting from scratch.
+
+Examples of work that could move this forward:
+
+- Intent representation and downstream-upstream linking ([#1336](https://github.com/fullsend-ai/fullsend/issues/1336), [#802](https://github.com/fullsend-ai/fullsend/issues/802))
+- Connecting feature specs to implementable units ([#1337](https://github.com/fullsend-ai/fullsend/issues/1337), [#1342](https://github.com/fullsend-ai/fullsend/issues/1342))
+
+Related: [downstream-upstream](problems/downstream-upstream.md), [intent-representation](problems/intent-representation.md)
+
+**Next**
+
+
+What follows once the current work stabilizes.
+
+**Trustworthiness evidence**
+
+
+We accumulate evidence about the quality of agent-produced code and reviews. This informs future decisions about expanding agent autonomy. The question is not whether to trust agents more, but where and when the evidence supports it.
+
+This area is thin on dedicated tracking issues — most related work is scattered across review agent improvements. Filing focused issues for measurement and evidence collection would help.
+
+Examples of work that could move this forward:
+
+- Rework rate tracking for agent-produced PRs
+- Review outcome analysis (accepted vs. discarded) ([#295](https://github.com/fullsend-ai/fullsend/issues/295))
+- Qualitative feedback collection from pilot teams
+
+**Standalone local runtime**
+
+
+A standalone runtime that allows agents to run locally, reducing dependence on GitHub Actions and providing a flexible execution alternative for teams hitting usage limits or needing offline capabilities.
+
+Examples of work that could move this forward:
+
+- Standalone dev mint server without GCP dependency ([#1963](https://github.com/fullsend-ai/fullsend/issues/1963))
+- Hosted mint defaults to reduce infrastructure requirements ([#1145](https://github.com/fullsend-ai/fullsend/issues/1145), [#2073](https://github.com/fullsend-ai/fullsend/issues/2073))
+- Local harness invocation support ([#173](https://github.com/fullsend-ai/fullsend/issues/173))
+- Self-hosted and network boundary support ([#595](https://github.com/fullsend-ai/fullsend/issues/595), [#918](https://github.com/fullsend-ai/fullsend/issues/918))
+
+**JIRA-driven workflows**
+
+
+With feature refinement establishing the pattern, extend agent capabilities deeper into project management — picking up stories, refining acceptance criteria, and linking implementation back to tracking. This extends fullsend's trigger model beyond forge events into project management systems.
+
+**Auto-merge readiness**
+
+
+With trustworthiness evidence accumulating, we begin reasoning about where auto-merge is safe — identifying specific codepaths or repositories where the evidence supports it and defining what the threshold looks like.
+
+Related: [autonomy-spectrum](problems/autonomy-spectrum.md), [code-review](problems/code-review.md)
+
+Examples of work that could move this forward:
+
+- Defining auto-merge criteria per repo or codepath ([#1574](https://github.com/fullsend-ai/fullsend/issues/1574), [#1772](https://github.com/fullsend-ai/fullsend/issues/1772))
+- Monitoring rework rates against thresholds
+- CODEOWNERS-based scope boundaries for auto-merge
+
+**Later**
+
+
+Problems we are actively thinking about but not yet building. These are informed by the [problem documents](problems/) and will move into **Next** as the platform matures.
+
+**Kubernetes and OpenShift execution**
+
+
+When the sandbox runtime matures to run practically in Kubernetes and OpenShift, fullsend should support that as an execution environment. This also opens the door to triggering agent workflows from sources beyond GitHub and GitLab — decoupling the agent runtime from the forge.
+
+**Production feedback loops**
+
+
+Closing the loop between production signals and what agents work on next. Platform organizations generate structured execution data that can drive triage and prioritization without waiting for humans to notice failures.
+
+- Related: [production-feedback](problems/production-feedback.md)
+
+**Cross-forge orchestration**
+
+
+Coordinating agent work across multiple forges (GitHub + GitLab, or multiple GitHub orgs) when a single logical change spans organizational boundaries.
+
+**Security hardening**
+
+
+Ongoing work informed by the [security threat model](problems/security-threat-model.md):
+
+- Prompt injection detection and andon cord ([#172](https://github.com/fullsend-ai/fullsend/issues/172), [#174](https://github.com/fullsend-ai/fullsend/issues/174))
+- Org guardrail protection ([#84](https://github.com/fullsend-ai/fullsend/issues/84))
+- Workflow security scanning ([#159](https://github.com/fullsend-ai/fullsend/issues/159))
+- Agent authority modeling ([#877](https://github.com/fullsend-ai/fullsend/issues/877))
+
+**Human factors and governance**
+
+
+As autonomous contribution scales, the organizational questions become unavoidable: domain ownership shifts, review fatigue, contributor motivation, and who has authority to make binding decisions about agent behavior.
+
+- Related: [human-factors](problems/human-factors.md), [governance](problems/governance.md), [contribution-volume](problems/contribution-volume.md)
+
+**Agent attestations**
+
+
+Cryptographic attestation of agent-produced artifacts, enabling consumers to verify what agent produced a change, under what policy, and with what inputs.
+
+- See [#267](https://github.com/fullsend-ai/fullsend/issues/267)
+
+
+
+
+---
+
+## Foundation — April–May 2026
+
+**When:** Published May 14, 2026 (post-MVP rewrite)
+**Source:** [`739bf26d`](https://github.com/fullsend-ai/fullsend/commit/739bf26d)
+**About this edition:** First Now/Next/Later roadmap after MVP. Captures what Foundation established and the immediate post-MVP Now work (WIF, per-repo install, OpenShell).
+
+### Foundation headline
+
+Fullsend reached MVP in April 2026. The platform can be installed at the org level, enroll repositories, and run a full autonomous SDLC loop: triage issues, produce code and tests, review PRs, apply fixes from review feedback, and file retrospective improvement proposals. The core agent suite — triage, code, review, fix, retro, and scribe — ships as **OOTB (out-of-the-box) agents** and is designed to be general, extensible, and replaceable.
+
+### Now
+
+- Secretless deployment (WIF)
+- Per-repo deployment
+- MVP feedback iteration
+- OpenShell improvements
+
+### Next
+
+- Bring Your Own Agent (BYOA)
+- Feature refinement
+- Auto-merge trustworthiness
+
+### Later
+
+- GitLab support
+- Kubernetes and OpenShift execution
+- JIRA-driven agent workflows
+- Cross-run memory
+- Production feedback loops
+- Operational observability
+- Security hardening
+- Human factors and governance
+
+
+Full published text — Foundation — April–May 2026 (click to expand)
+
+Where fullsend is, and where it is going. Organized as **Now / Next / Later** — what we are actively building, what follows immediately after, and what we see on the horizon.
+
+**Foundation (done)**
+
+
+Fullsend reached MVP in April 2026. The platform can be installed at the org level, enroll repositories, and run a full autonomous SDLC loop: triage issues, produce code and tests, review PRs, apply fixes from review feedback, and file retrospective improvement proposals. The core agent suite — triage, code, review, fix, retro, and scribe — ships as **OOTB (out-of-the-box) agents** and is designed to be general, extensible, and replaceable.
+
+What this phase established:
+
+- **Binary autonomy model** — per-repo opt-in, CODEOWNERS enforcing human approval on protected paths
+- **The repo is the coordinator** — branch protection, CODEOWNERS, and status checks replace a coordinator agent
+- **Trust derives from repository permissions, not agent identity**
+- **Fullsend is using fullsend** — the platform dogfoods its own agent workflows
+- **10+ Konflux repositories** running fullsend for bug triage, code production, and review
+- **Active engagement** with additional upstream organizations exploring adoption
+
+**Now**
+
+
+What we are actively building and shipping.
+
+**Secretless deployment (WIF)**
+
+
+Replace long-lived credentials with Workload Identity Federation. This is a prerequisite for per-repo deployment and a security improvement for existing org-level installs.
+
+- See [#912](https://github.com/fullsend-ai/fullsend/issues/912), [#913](https://github.com/fullsend-ai/fullsend/issues/913), [#914](https://github.com/fullsend-ai/fullsend/issues/914), [#915](https://github.com/fullsend-ai/fullsend/issues/915)
+
+**Per-repo deployment**
+
+
+Org-level installation is appropriate for some organizations but inappropriate for others. Per-repo deployment lets individual repositories adopt fullsend without requiring org-wide configuration — lowering the barrier for new organizations and enabling adoption in orgs where org-level access is impractical.
+
+**MVP feedback iteration**
+
+
+Incorporating feedback from early adopters. The issue backlog reflects this ongoing work across all agents:
+
+- Review agent stability and accuracy ([#947](https://github.com/fullsend-ai/fullsend/issues/947), [#898](https://github.com/fullsend-ai/fullsend/issues/898), [#925](https://github.com/fullsend-ai/fullsend/issues/925), [#887](https://github.com/fullsend-ai/fullsend/issues/887))
+- Review-fix feedback loop improvements ([#902](https://github.com/fullsend-ai/fullsend/issues/902), [#870](https://github.com/fullsend-ai/fullsend/issues/870), [#924](https://github.com/fullsend-ai/fullsend/issues/924))
+- Code agent reliability ([#934](https://github.com/fullsend-ai/fullsend/issues/934), [#935](https://github.com/fullsend-ai/fullsend/issues/935), [#871](https://github.com/fullsend-ai/fullsend/issues/871))
+- Operational improvements ([#896](https://github.com/fullsend-ai/fullsend/issues/896), [#909](https://github.com/fullsend-ai/fullsend/issues/909), [#893](https://github.com/fullsend-ai/fullsend/issues/893))
+
+**OpenShell improvements**
+
+
+Pulling in new OpenShell features as they become available, including package-based installation ([#878](https://github.com/fullsend-ai/fullsend/issues/878)) and host-side API server capabilities ([#879](https://github.com/fullsend-ai/fullsend/issues/879), [#880](https://github.com/fullsend-ai/fullsend/issues/880), [#881](https://github.com/fullsend-ai/fullsend/issues/881)).
+
+**Next**
+
+
+What follows once the current work stabilizes.
+
+**Bring Your Own Agent (BYOA)**
+
+
+The OOTB agents are designed to be good defaults, but many teams will want super-custom, super-bespoke agentic workflows that we could never anticipate. BYOA enables teams to use fullsend as a framework — plugging in their own agents, skills, and orchestration while inheriting the platform's security model, sandbox isolation, and coordination layer.
+
+This is a foundational capability. It transforms fullsend from a fixed agent suite into an extensible platform.
+
+- Harness definition architecture ([#173](https://github.com/fullsend-ai/fullsend/issues/173), [#101](https://github.com/fullsend-ai/fullsend/issues/101))
+- Skills loading policy and org/repo inheritance ([#237](https://github.com/fullsend-ai/fullsend/issues/237), [#236](https://github.com/fullsend-ai/fullsend/issues/236))
+- Per-repo workflow definitions ([#69](https://github.com/fullsend-ai/fullsend/issues/69))
+- Config schema and versioning ([#179](https://github.com/fullsend-ai/fullsend/issues/179), [#235](https://github.com/fullsend-ai/fullsend/issues/235))
+
+**Feature refinement**
+
+
+Extending the SDLC footprint beyond bug triage and code production into feature work: refining feature requests, breaking them into implementable units, prioritizing them, and linking that process to upstream agentic development.
+
+- Related: [downstream-upstream](problems/downstream-upstream.md), [intent-representation](problems/intent-representation.md)
+
+**Auto-merge trustworthiness**
+
+
+Monitoring rework rates and review outcomes to build confidence in auto-merge for specific codepaths and repositories. The question is not whether to auto-merge but where and when the evidence supports it.
+
+- Related: [autonomy-spectrum](problems/autonomy-spectrum.md), [code-review](problems/code-review.md)
+
+**Later**
+
+
+Problems we are actively thinking about but not yet building. These are informed by the [problem documents](problems/) and will move into **Next** as the platform matures.
+
+**GitLab support**
+
+
+GitHub is the starting point, not the boundary. GitLab support requires solving webhook-to-pipeline translation, MR-event security models, and forge interface abstraction. The architectural groundwork is laid in [ADR-0028](ADRs/0028-gitlab-support.md).
+
+- Related: [gitlab-implementation](problems/gitlab-implementation.md)
+
+**Kubernetes and OpenShift execution**
+
+
+When OpenShell matures to run practically in Kubernetes and OpenShift, fullsend should support that as an execution environment. This also opens the door to triggering agent workflows from sources beyond GitHub and GitLab — decoupling the agent runtime from the forge.
+
+**JIRA-driven agent workflows**
+
+
+Agents that work directly off JIRA issues — picking up stories, refining acceptance criteria, and linking implementation back to tracking. This extends fullsend's trigger model beyond forge events into project management systems.
+
+**Cross-run memory**
+
+
+Agents are stateless by design, but they rediscover the same lessons on every run. The hard problem is preserving useful operational knowledge without creating a second, less-reviewed instruction channel.
+
+- Related: [cross-run-memory](problems/cross-run-memory.md)
+
+**Production feedback loops**
+
+
+Closing the loop between production signals and what agents work on next. Platform organizations generate structured execution data that can drive triage and prioritization without waiting for humans to notice failures.
+
+- Related: [production-feedback](problems/production-feedback.md)
+
+**Operational observability**
+
+
+How do the humans operating an autonomous software factory understand what it is doing, debug it when it goes wrong, and improve it over time?
+
+- Related: [operational-observability](problems/operational-observability.md)
+
+**Security hardening**
+
+
+Ongoing work informed by the [security threat model](problems/security-threat-model.md):
+
+- Prompt injection detection and andon cord ([#172](https://github.com/fullsend-ai/fullsend/issues/172), [#174](https://github.com/fullsend-ai/fullsend/issues/174))
+- Org guardrail protection ([#84](https://github.com/fullsend-ai/fullsend/issues/84))
+- Workflow security scanning ([#159](https://github.com/fullsend-ai/fullsend/issues/159))
+- Agent authority modeling ([#877](https://github.com/fullsend-ai/fullsend/issues/877))
+
+**Human factors and governance**
+
+
+As autonomous contribution scales, the organizational questions become unavoidable: domain ownership shifts, review fatigue, contributor motivation, and who has authority to make binding decisions about agent behavior.
+
+- Related: [human-factors](problems/human-factors.md), [governance](problems/governance.md), [contribution-volume](problems/contribution-volume.md)
+
+
diff --git a/docs/problems/platform-nativeness.md b/docs/problems/platform-nativeness.md
index c8bec6658e..37ea7bc120 100644
--- a/docs/problems/platform-nativeness.md
+++ b/docs/problems/platform-nativeness.md
@@ -153,7 +153,7 @@ gh-aw's container isolation is strong for its use case, but the isolation bounda
- **Should fullsend adopt gh-aw as its containment and execution layer?** Rather than building parallel infrastructure for cross-repo dispatch, credential isolation, and agent sandboxing, fullsend could use gh-aw directly for the containment layer and focus its engineering effort on the judgment layer (intent verification, review composition, merge authority). gh-aw workflows are markdown files — agents can author them, aided by gh-aw's own [documentation MCP server](https://github.github.com/gh-aw/reference/gh-aw-as-mcp-server/). The `gh aw` CLI already handles compilation, security scanning, and lock file generation. Fullsend would not need to replicate any of this.
-- **Is the forge abstraction worth the cost at this stage?** Fullsend's only concrete implementation is GitHub. If forge-neutrality is deferred to the [Infrastructure](../roadmap.md#infrastructure) and [Cross-forge orchestration](../roadmap.md#cross-forge-orchestration) work in the [roadmap](../roadmap.md), the current implementation could use GitHub-native primitives directly, simplifying the stack substantially.
+- **Is the forge abstraction worth the cost at this stage?** Fullsend's only concrete implementation is GitHub. If forge-neutrality is deferred to GitLab MVP, cross-forge orchestration, and Kubernetes/OpenShift work on the [roadmap](../roadmap.md), the current implementation could use GitHub-native primitives directly, simplifying the stack substantially.
- **Can gh-aw's safe-outputs model be extended for autonomous merge?** This is no longer hypothetical — gh-aw shipped an experimental `merge-pull-request` safe-output (introduced via [PR #27193](https://github.com/github/gh-aw/pull/27193), merged 2026-04-20, and refined further in the June 2026 v0.80.4/v0.81.0 releases), gated by required status checks, review decision, unresolved-thread state, labels, and branch allowlists, with default-branch merges always refused and `gh aw compile` flagging it as experimental. The open question is narrower now: whether/when it graduates to stable, how permissive its policy gates become, and whether it ever gates on anything beyond a prior human review decision (i.e., autonomous *judgment* about the change, not just mechanical merge-after-approval) — which is where fullsend's thesis remains differentiated.
diff --git a/docs/roadmap.md b/docs/roadmap.md
index afc432eed1..693e2f8526 100644
--- a/docs/roadmap.md
+++ b/docs/roadmap.md
@@ -1,232 +1,86 @@
# Roadmap
-Where fullsend is, and where it is going. Organized as **Now / Next / Later** — what we are actively building, what follows immediately after, and what we see on the horizon.
-
-Categories are listed in the priority order established at the [July 1 planning session](#now). The ordering reflects team dot-voting decisions.
-
-## At a glance
-
-| Priority | Category | Focus | Horizon |
-|:--------:|----------|-------|:-------:|
-| 1 | [**BYOA**](#byoa) | Agent catalog, harness triggers, config knobs, shareable config profiles | Now |
-| 2 | [**Infrastructure**](#infrastructure) | Drop per-org, unify installs, version pinning, OpenShell improvements, GitLab, OpenCode | Now |
-| 3 | [**Observability**](#observability) | Cost measurement, telemetry phase 2 & 3, surfacing hidden agent failures | Now |
-| 4 | [**Testing**](#testing) | Behavior tests for deterministic code, functional tests for all agents, evals, stage tests | Now |
-| 5 | [**External Partnerships**](#external-partnerships) | OpenShell/Ansible/TektonCD using fullsend, community building, docs improvements | Now |
-| 6 | [**JIRA**](#jira) | JIRA support for all default agents, mint for JIRA | Now |
-| 7 | [**mint**](#mint) | Extract mint repo, finish public mint, e2e tests, move to prod GCP project | Now |
-| 8 | [**Agent Data Access**](#agent-data-access) | Data connectors (JIRA, GitLab, Slack), multi-repo context, agent environment planning | Now |
-| 9 | [**Exploration**](#exploration) | Persistent agent memories, auto-merge (tiny percentage) | Next |
-| — | [Cross-forge orchestration](#cross-forge-orchestration) | Coordinating agent work across GitHub + GitLab orgs | Next |
-| — | [Kubernetes and OpenShift execution](#kubernetes-and-openshift-execution) | K8s/OpenShift as agent runtime | Later |
-| — | [Security hardening](#security-hardening) | Prompt injection defense, credential isolation, threat model | Later |
-| — | [Human factors and governance](#human-factors-and-governance) | Domain ownership, review fatigue, contributor motivation | Later |
-| — | [Production feedback loops](#production-feedback-loops) | Production signals driving triage and prioritization | Later |
-| — | [Agent attestations](#agent-attestations) | Cryptographic provenance for agent output | Later |
-
-## June 2026 (done)
-
-June focused on platform architecture maturation, harness portability, review agent reliability, and developer experience. Over 90 PRs merged and 150+ issues closed.
-
-What this phase delivered:
-
-- **Agent registration and BYOA foundations** — ADR 0058 landed in three phases: agent registration schema, `fullsend agent` CLI subcommand, and runtime agent resolution from config ([#2768](https://github.com/fullsend-ai/fullsend/pull/2768), [#2769](https://github.com/fullsend-ai/fullsend/pull/2769), [#2770](https://github.com/fullsend-ai/fullsend/pull/2770))
-- **Unified env var delivery** — ADR 0055 unified runner and sandbox environment variable delivery, with all default agents migrated to the new `env.runner`/`env.sandbox` schema ([#2582](https://github.com/fullsend-ai/fullsend/pull/2582), [#2763](https://github.com/fullsend-ai/fullsend/pull/2763), [#2762](https://github.com/fullsend-ai/fullsend/pull/2762), [#2759](https://github.com/fullsend-ai/fullsend/pull/2759))
-- **PR-based scaffold delivery** — install now defaults to creating PRs instead of pushing directly to the default branch, with `--direct` flag for the old behavior and fork support for non-owner users ([#2533](https://github.com/fullsend-ai/fullsend/pull/2533), [#2630](https://github.com/fullsend-ai/fullsend/pull/2630))
-- **Docs site migration** — migrated from Docusaurus to VitePress with a redesigned landing page, mermaid diagram rendering, and sidebar ordering control ([#2721](https://github.com/fullsend-ai/fullsend/pull/2721), [#2701](https://github.com/fullsend-ai/fullsend/pull/2701), [#2754](https://github.com/fullsend-ai/fullsend/pull/2754))
-- **Dispatch hardening** — label-based gating for agent dispatch (ADR 0054), retro dispatch skip guards for bot dependency PRs, and rate-limit retry improvements ([#2679](https://github.com/fullsend-ai/fullsend/pull/2679), [#2764](https://github.com/fullsend-ai/fullsend/pull/2764))
-- **Review agent reliability** — review sub-agent depth scaling, challenger pass dedicated sub-agent, line-number verification, finding deduplication, and severity-aligned verdicts ([#2695](https://github.com/fullsend-ai/fullsend/pull/2695))
-- **OpenShell tracking** — tracked OpenShell through versions 0.0.38 to 0.0.72, resolving sandbox boundary checks, nftables requirements, JWT auth conflicts, and supervisor image pinning ([#1763](https://github.com/fullsend-ai/fullsend/issues/1763), [#1764](https://github.com/fullsend-ai/fullsend/issues/1764), [#1765](https://github.com/fullsend-ai/fullsend/issues/1765), [#1766](https://github.com/fullsend-ai/fullsend/issues/1766), [#1768](https://github.com/fullsend-ai/fullsend/issues/1768))
-- **Renovate enablement** — self-hosted Renovate GitHub App with automerge for low-risk dependency PRs ([#2480](https://github.com/fullsend-ai/fullsend/pull/2480), [#2546](https://github.com/fullsend-ai/fullsend/pull/2546))
-- **Agent status comments** — agents now post status comments on workflow start and completion, with timeline analysis and token-expiry resilience ([#1859](https://github.com/fullsend-ai/fullsend/issues/1859))
-- **Security hardening** — all GitHub Actions pinned to full-length commit SHAs, DCO enforcement, SRI attributes on CDN scripts ([#2508](https://github.com/fullsend-ai/fullsend/pull/2508), [#2509](https://github.com/fullsend-ai/fullsend/pull/2509))
-- **E2e expansion** — org pool expanded from 6 to 12, fork PR support, functional test gates with collaborator permission fallback ([#2766](https://github.com/fullsend-ai/fullsend/pull/2766))
-- **Standalone runtime progress** — standalone mint with custom role support shipped ([#2537](https://github.com/fullsend-ai/fullsend/pull/2537)), default `--mint-url` now points to hosted public mint removing GCP provisioning requirement ([#2073](https://github.com/fullsend-ai/fullsend/issues/2073)), `fullsend run` wired with Lint diagnostics and `LoadWithBase` pipelines ([#2362](https://github.com/fullsend-ai/fullsend/pull/2362), [#2224](https://github.com/fullsend-ai/fullsend/pull/2224)), and `--vendor` flag for self-contained workflow assets ([#2145](https://github.com/fullsend-ai/fullsend/issues/2145))
-- **Harness CEL dispatch** — ADR for harness-level CEL dispatch and NormalizedEvent v1 landed ([#2650](https://github.com/fullsend-ai/fullsend/pull/2650))
-- **URL-based harness composition** — resolved scripts, skills, and declarative resources from URL-referenced base harnesses ([#2525](https://github.com/fullsend-ai/fullsend/pull/2525), [#2690](https://github.com/fullsend-ai/fullsend/pull/2690), [#2707](https://github.com/fullsend-ai/fullsend/pull/2707))
+Where fullsend is going, organized by delivery horizon from the July 28, 2026 planning session:
-## Now
-
-What we are actively building and shipping. Categories are ordered by priority from the July 2026 planning session.
-
-### BYOA
-
-Making fullsend a platform teams can adopt incrementally and extend freely. This is the team's highest priority for July — driven by user demand for custom agents, better configuration, and simplified adoption.
-
-The custom agent interface needs to be clean enough that replatforming an existing agent is straightforward, not a rewrite. Easy local agent runs let users test-drive custom agents and skills before wiring them into CI. An agent catalog (an "awesome list" style repository for discovering and sharing agent definitions) will make the ecosystem more visible and navigable. Shareable config profiles let teams preconfigure a deployment with a single URL. Scribe agent enhancements address multiple outstanding user requests and will move to the agents repo as part of the re-platforming effort.
-
-Examples of work that could move this forward:
-
-- Harness triggers and dynamic agent dispatching ([#2565](https://github.com/fullsend-ai/fullsend/issues/2565))
-- Major config knobs for agents — making agents more adaptable to user preferences ([#2832](https://github.com/fullsend-ai/fullsend/issues/2832))
-- Scribe agent enhancements and migration to agents repo ([#895](https://github.com/fullsend-ai/fullsend/issues/895), [#222](https://github.com/fullsend-ai/fullsend/issues/222), [#1674](https://github.com/fullsend-ai/fullsend/issues/1674))
-- Re-platform default agents as harness-driven configs ([#1986](https://github.com/fullsend-ai/fullsend/issues/1986), [#1985](https://github.com/fullsend-ai/fullsend/issues/1985))
-- Harness definition architecture and config schema ([#173](https://github.com/fullsend-ai/fullsend/issues/173), [#179](https://github.com/fullsend-ai/fullsend/issues/179), [#235](https://github.com/fullsend-ai/fullsend/issues/235))
-- Skills loading policy and org/repo inheritance ([#237](https://github.com/fullsend-ai/fullsend/issues/237), [#236](https://github.com/fullsend-ai/fullsend/issues/236))
-- Selective agent enablement in config ([#581](https://github.com/fullsend-ai/fullsend/issues/581), [#604](https://github.com/fullsend-ai/fullsend/issues/604))
-- Authorization model for agent invocations ([#1662](https://github.com/fullsend-ai/fullsend/issues/1662), [#1687](https://github.com/fullsend-ai/fullsend/issues/1687))
-- Provider and profile resolution from URL-referenced bases ([#2672](https://github.com/fullsend-ai/fullsend/issues/2672))
-- Easy local agent runs — test drive custom agents and skills locally ([#1963](https://github.com/fullsend-ai/fullsend/issues/1963), [#595](https://github.com/fullsend-ai/fullsend/issues/595))
-
-### Infrastructure
-
-Platform infrastructure, technical debt reduction, and runtime improvements. This category consolidates what was previously split across "Agent Capabilities & Runtime", "Upgrades & Versioning", and "New Forges" from the June plan — the team recognized these share enough infrastructure overlap to manage together.
-
-Key themes: deprecating per-org installs in favor of a unified approach, version pinning and automatic upgrades, OpenShell improvements (Go SDK migration, API extensibility, Vertex API authorization fixes), running agents outside GitHub Actions (GitLab, Tekton infrastructure), and OpenCode alignment with the global engineering working group.
-
-Examples of work that could move this forward:
-
-- Drop per-org installs — deprecate and remove in favor of unified install ([#2454](https://github.com/fullsend-ai/fullsend/issues/2454), [#2302](https://github.com/fullsend-ai/fullsend/issues/2302))
-- Version pinning and automatic upgrades ([#1933](https://github.com/fullsend-ai/fullsend/issues/1933), [#2454](https://github.com/fullsend-ai/fullsend/issues/2454))
-- OpenShell improvements — simplification, Go SDK migration, API extensibility, Vertex authorization fixes ([#2692](https://github.com/fullsend-ai/fullsend/issues/2692))
-- GitLab support — webhook bridge, GitLab CI as trigger/coordination layer ([#1964](https://github.com/fullsend-ai/fullsend/issues/1964))
-- Forge-portable harness schema ([#1605](https://github.com/fullsend-ai/fullsend/issues/1605))
-- OpenCode alignment with global engineering working group ([#1260](https://github.com/fullsend-ai/fullsend/issues/1260), [#1935](https://github.com/fullsend-ai/fullsend/issues/1935))
-- Refactor runAgent for testability ([#2831](https://github.com/fullsend-ai/fullsend/issues/2831))
-
-### Observability
-
-Understanding what agents cost, how they perform, and where they silently fail. This is a new category for July — elevated because users are increasingly asking for visibility into agent behavior and costs.
-
-A key problem surfaced in the planning session: agents can silently repeat the same mistakes across separate runs with no mechanism to surface previous failures. Cost measurement and aggregation will help teams understand their agent usage. Telemetry phase 2 & 3 build on existing tracing foundations to provide deeper operational insight.
-
-Examples of work that could move this forward:
-
-- Cost measurement and aggregation — per-repo and per-agent token/cost tracking ([#2668](https://github.com/fullsend-ai/fullsend/issues/2668))
-- Telemetry phase 2 & 3 — OpenTelemetry Go SDK for trace export ([#2780](https://github.com/fullsend-ai/fullsend/issues/2780)), trace chain integrity ([#2779](https://github.com/fullsend-ai/fullsend/issues/2779))
-- Agent error visibility — handling `is_error:true` responses from runtimes ([#2786](https://github.com/fullsend-ai/fullsend/issues/2786))
-- OIDC token staleness when sandbox setup exceeds timeout ([#2783](https://github.com/fullsend-ai/fullsend/issues/2783))
-- Release summary bot for automated changelog visibility ([#2778](https://github.com/fullsend-ai/fullsend/issues/2778))
-
-### Testing
-
-How we gain confidence in what we ship. Building comprehensive testing infrastructure across behavioral tests, functional tests, evaluation frameworks, and staging environments.
-
-The team identified a gap between how e2e tests work (vendored files, per-commit tricks) and how users actually use fullsend. Stage tests running post-merge in a staging environment will close this gap and provide more realistic validation.
-
-Examples of work that could move this forward:
-
-- Behavior tests for deterministic code paths — tests that validate without running LLMs ([#346](https://github.com/fullsend-ai/fullsend/issues/346))
-- Evaluation frameworks — SWE-bench pilot, Harbor for code-agent outcome eval ([#2510](https://github.com/fullsend-ai/fullsend/issues/2510))
-- Statistical significance layer for non-deterministic evals ([#2460](https://github.com/fullsend-ai/fullsend/issues/2460))
-- E2e test improvements — bot authorization fixes, auth alignment ([#2641](https://github.com/fullsend-ai/fullsend/issues/2641), [#2772](https://github.com/fullsend-ai/fullsend/issues/2772), [#2489](https://github.com/fullsend-ai/fullsend/issues/2489))
-- Trustworthiness evidence — rework rate tracking, review outcome analysis ([#295](https://github.com/fullsend-ai/fullsend/issues/295))
-
-### External Partnerships
-
-Making fullsend visible, understandable, and usable by teams outside the core group. This category combines documentation improvements with active partnership engagement — recognizing that docs quality and external adoption are tightly linked.
-
-Multiple teams are actively using or evaluating fullsend: OpenShell, Ansible, TektonCD, and potential enterprise partnerships. The Tekton CI team is hitting GitHub Actions resource limits, making non-GHA execution an increasingly relevant concern. Documentation improvements are a direct response to user feedback — people are adopting fullsend but struggling with the docs. The team plans to schedule screen-share sessions with users to observe how they interpret documentation and identify friction points.
-
-Examples of work that could move this forward:
+- **Now** — August 2026 window (~30 days)
+- **Next** — matters, but not promised this month
+- **Later** — on the horizon
-- Docs site experiments content and public mint docs ([#2757](https://github.com/fullsend-ai/fullsend/issues/2757))
-- Document maintainer onboarding process ([#2653](https://github.com/fullsend-ai/fullsend/issues/2653))
-- JIRA data leakage risk documentation for public repos ([#2513](https://github.com/fullsend-ai/fullsend/issues/2513))
+Items are listed in planning order, not priority rank. Tracking spans [fullsend-ai/fullsend](https://github.com/fullsend-ai/fullsend) and [fullsend-ai/agents](https://github.com/fullsend-ai/agents) (best-effort). The team also does maintenance and platform work that is not listed here.
-### JIRA
+Earlier published roadmaps and rotated milestone sections (Foundation, prior monthly done recaps) live in [archived-roadmap.md](archived-roadmap.md) for history only.
-Connecting fullsend to JIRA — extending the trigger model beyond forge events into project management. This is focused specifically on making fullsend agents work with JIRA data and workflows.
-
-The scope covers JIRA support across all default agents (not just triage), credential management for JIRA service accounts, and the possibility of a dedicated mint for JIRA using Workload Identity Federation. The plan is to start with public JIRA projects to avoid private data exposure.
-
-Examples of work that could move this forward:
-
-- JIRA support for all default agents — triage ([#2264](https://github.com/fullsend-ai/fullsend/issues/2264)), code ([#2265](https://github.com/fullsend-ai/fullsend/issues/2265)), prioritize ([#2266](https://github.com/fullsend-ai/fullsend/issues/2266)), retro ([#2267](https://github.com/fullsend-ai/fullsend/issues/2267)), review ([#2268](https://github.com/fullsend-ai/fullsend/issues/2268)), refine ([#1341](https://github.com/fullsend-ai/fullsend/issues/1341))
-- JIRA trigger model ([#2263](https://github.com/fullsend-ai/fullsend/issues/2263))
-- Mint for JIRA — Workload Identity Federation for JIRA service accounts ([#2269](https://github.com/fullsend-ai/fullsend/issues/2269))
-
-Related: [downstream-upstream](problems/downstream-upstream.md), [intent-representation](problems/intent-representation.md)
-
-### mint
-
-Extracting, hardening, and operationalizing the token mint as a standalone service. The mint is already fairly standalone in the codebase — this work completes the separation, adds proper test coverage, and moves it to production infrastructure. Longer-term goals include extracting the mint into its own repository and migrating mint infrastructure to a dedicated GCP project separate from dev/inference.
-
-Examples of work that could move this forward:
-
-- Finish public mint work — implementing ADR 0059 public mint mode ([#2773](https://github.com/fullsend-ai/fullsend/pull/2773), [#2073](https://github.com/fullsend-ai/fullsend/issues/2073))
-- mint delete command for infrastructure teardown ([#2680](https://github.com/fullsend-ai/fullsend/issues/2680))
-- Token caching with safe refresh across nested CLI invocations ([#2542](https://github.com/fullsend-ai/fullsend/issues/2542))
-- Consolidate agent role lists and permission definitions ([#2449](https://github.com/fullsend-ai/fullsend/issues/2449))
-- Evaluate database-backed persistence for mint identity ([#2564](https://github.com/fullsend-ai/fullsend/issues/2564))
-- Mint service decomposition criteria ([#2437](https://github.com/fullsend-ai/fullsend/issues/2437))
-- Deployment suggestions and health check capabilities ([#2438](https://github.com/fullsend-ai/fullsend/issues/2438))
-
-### Agent Data Access
-
-Giving agents access to data beyond the repository — JIRA, GitLab, Slack, Google Drive, and multi-repo context. This is distinct from the JIRA category (which focuses on JIRA-specific workflows) and addresses the broader challenge of connecting agents to external data sources securely.
+## Now
-The team recognized this requires more than just adding skills: it involves credential management, network policies, service accounts, and context-aware loading for data sources like JIRA, GitLab, Slack, and Google Drive. ADRs are needed before implementation to establish patterns rather than accumulating ad-hoc integrations.
-Examples of work that could move this forward:
+| Deliverable | Outcome | Tracking |
+| ------------------------------------------ | -------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| PR risk assessment | Risk signal on PRs | [fullsend#4698](https://github.com/fullsend-ai/fullsend/issues/4698) |
+| Basic auto-merge capability | Smallest safe foothold + config | [fullsend#2791](https://github.com/fullsend-ai/fullsend/issues/2791) · [fullsend#3016](https://github.com/fullsend-ai/fullsend/issues/3016) |
+| Review-fix loop | Less human mechanical iteration | [fullsend#5666](https://github.com/fullsend-ai/fullsend/issues/5666) · [fullsend#5550](https://github.com/fullsend-ai/fullsend/issues/5550) · [agents#447](https://github.com/fullsend-ai/agents/issues/447) · [agents#343](https://github.com/fullsend-ai/agents/issues/343) · [agents#478](https://github.com/fullsend-ai/agents/issues/478) |
+| Versioned docs | Better docs experience for users | [fullsend#5717](https://github.com/fullsend-ai/fullsend/issues/5717) · [fullsend#5718](https://github.com/fullsend-ai/fullsend/issues/5718) |
+| Contributor meeting | Broader contributor call | — |
+| Agent contribution example | Help users see how to improve fullsend; make it easier to contribute | [fullsend#5720](https://github.com/fullsend-ai/fullsend/issues/5720) |
+| Per-workflow cost visibility | Cost by workflow type | [fullsend#5361](https://github.com/fullsend-ai/fullsend/issues/5361) · [fullsend#5537](https://github.com/fullsend-ai/fullsend/issues/5537) |
+| Jira poller | Jira events → agents | [fullsend#3812](https://github.com/fullsend-ai/fullsend/issues/3812) · [fullsend#4885](https://github.com/fullsend-ai/fullsend/issues/4885) · [fullsend#3428](https://github.com/fullsend-ai/fullsend/issues/3428) · [fullsend#2269](https://github.com/fullsend-ai/fullsend/issues/2269) |
+| Example custom agent that responds to Jira | BYOA pattern for Jira | [fullsend#3812](https://github.com/fullsend-ai/fullsend/issues/3812) |
+| Triage agent works in response to Jira | Default triage from Jira | [fullsend#2264](https://github.com/fullsend-ai/fullsend/issues/2264) |
+| Make agent status comments configurable | Reduce agent spam on issues for users who don't want it | [fullsend#3697](https://github.com/fullsend-ai/fullsend/issues/3697) |
+| Customer validation | Customer research and validation support | — |
+| BYOA API servers | Host-side APIs for sandboxes | [fullsend#879](https://github.com/fullsend-ai/fullsend/issues/879) · [fullsend#881](https://github.com/fullsend-ai/fullsend/issues/881) · [fullsend#5242](https://github.com/fullsend-ai/fullsend/issues/5242) · [fullsend#5243](https://github.com/fullsend-ai/fullsend/issues/5243) |
+| Multi-endpoint telemetry / storage | Multi-endpoint telemetry and storage | [fullsend#5545](https://github.com/fullsend-ai/fullsend/issues/5545) · [fullsend#5533](https://github.com/fullsend-ai/fullsend/issues/5533) · [fullsend#294](https://github.com/fullsend-ai/fullsend/issues/294) |
+| GitLab MVP | Usable GitLab path | [fullsend#1964](https://github.com/fullsend-ai/fullsend/issues/1964) · [fullsend#5556](https://github.com/fullsend-ai/fullsend/issues/5556) |
+| Remove per-org install | Unified install | [fullsend#2302](https://github.com/fullsend-ai/fullsend/issues/2302) · [fullsend#2887](https://github.com/fullsend-ai/fullsend/issues/2887) · [fullsend#5197](https://github.com/fullsend-ai/fullsend/issues/5197) |
+| Public mint | Finish and operate public mint | [fullsend#5116](https://github.com/fullsend-ai/fullsend/issues/5116) · [fullsend#5115](https://github.com/fullsend-ai/fullsend/issues/5115) · [fullsend#5634](https://github.com/fullsend-ai/fullsend/issues/5634) |
+| Roll out repos management | Repos + mint operable | [fullsend#181](https://github.com/fullsend-ai/fullsend/issues/181) |
+| Doc use cases and practices | Copyable practices | [fullsend#419](https://github.com/fullsend-ai/fullsend/issues/419) · [fullsend#5372](https://github.com/fullsend-ai/fullsend/issues/5372) |
+| Shared configs | Ready-made / shareable presets | [fullsend#4910](https://github.com/fullsend-ai/fullsend/issues/4910) · [fullsend#4914](https://github.com/fullsend-ai/fullsend/issues/4914) |
-- Multi-repo context loading and cross-repo changes ([#298](https://github.com/fullsend-ai/fullsend/issues/298), [#401](https://github.com/fullsend-ai/fullsend/issues/401), [#1276](https://github.com/fullsend-ai/fullsend/issues/1276))
-- Secretless deployment and credential management strategies ([#1952](https://github.com/fullsend-ai/fullsend/issues/1952), [#1604](https://github.com/fullsend-ai/fullsend/issues/1604))
-- Least-privilege path for workflow file changes ([#2822](https://github.com/fullsend-ai/fullsend/issues/2822))
-- Human-gated permission adjustments ([#2821](https://github.com/fullsend-ai/fullsend/issues/2821), [#2829](https://github.com/fullsend-ai/fullsend/issues/2829))
## Next
-What follows once the current work stabilizes.
-
-### Exploration
-
-Ideas the team is actively thinking about but not yet committed to building. These received no votes in the July planning session but are tracked for future consideration.
-- **Persistent agent memories** — agents retain context and history across sessions, enabling learning from past mistakes. The team agreed this must be traceable and transparent to humans — hidden memory is rejected. Security concerns around persistent threats through memory injection need resolution before this moves forward.
-- **Auto-merge (tiny percentage)** — beginning to reason about where auto-merge is safe, starting with a very small percentage of changes where trustworthiness evidence supports it. Related: [autonomy-spectrum](problems/autonomy-spectrum.md), [code-review](problems/code-review.md), ADR 0062 ([#2791](https://github.com/fullsend-ai/fullsend/pull/2791))
+| Deliverable | Outcome | Tracking |
+| ------------------------------------------- | ----------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| Code agent works in response to Jira | Code agent from Jira | [fullsend#2265](https://github.com/fullsend-ai/fullsend/issues/2265) |
+| Multi-agent stages with their own sandboxes | Per-stage isolation (ADR-first) | [fullsend#3978](https://github.com/fullsend-ai/fullsend/issues/3978) |
+| Scheduled custom agents | Cron / scheduled runs | [fullsend#313](https://github.com/fullsend-ai/fullsend/issues/313) · [agents#442](https://github.com/fullsend-ai/agents/issues/442) |
+| Eval scenarios | Concrete eval measurements | [agents#209](https://github.com/fullsend-ai/agents/issues/209) · [agents#180](https://github.com/fullsend-ai/agents/issues/180) |
+| Increase SIT / reduce functional tests | More behaviour/SIT; less overlapping functional | [fullsend#3236](https://github.com/fullsend-ai/fullsend/issues/3236) · [fullsend#3786](https://github.com/fullsend-ai/fullsend/issues/3786) |
+| Multi-target repo for PR creation | PRs across more than one target repo | [fullsend#298](https://github.com/fullsend-ai/fullsend/issues/298) · [fullsend#1276](https://github.com/fullsend-ai/fullsend/issues/1276) |
+| Propose OpenShell to use fullsend | Partnership, not a chore | — |
+| GPG-signed commits from code and fix | Signed commits (e.g. Ansible) | [fullsend#5165](https://github.com/fullsend-ai/fullsend/issues/5165) · [agents#357](https://github.com/fullsend-ai/agents/issues/357) · [agents#318](https://github.com/fullsend-ai/agents/issues/318) |
+| Working OpenCode implementation | OpenCode as a runtime | [fullsend#1260](https://github.com/fullsend-ai/fullsend/issues/1260) |
+| Persistent agent memories | Traceable only; no hidden memory | — |
+| Cross-forge orchestration | GitHub + GitLab / multi-org | — |
-### Cross-forge orchestration
-
-Coordinating agent work across multiple forges (GitHub + GitLab, or multiple GitHub orgs) when a single logical change spans organizational boundaries.
## Later
-Problems we are actively thinking about but not yet building. These are informed by the [problem documents](problems/) and will move into **Next** as the platform matures.
-
-### Kubernetes and OpenShift execution
-
-When the sandbox runtime matures to run practically in Kubernetes and OpenShift, fullsend should support that as an execution environment. This also opens the door to triggering agent workflows from sources beyond GitHub and GitLab — decoupling the agent runtime from the forge.
-
-### Security hardening
-
-Ongoing work informed by the [security threat model](problems/security-threat-model.md):
-
-- Prompt injection detection and andon cord ([#172](https://github.com/fullsend-ai/fullsend/issues/172), [#174](https://github.com/fullsend-ai/fullsend/issues/174))
-- Org guardrail protection ([#84](https://github.com/fullsend-ai/fullsend/issues/84))
-- Workflow security scanning ([#159](https://github.com/fullsend-ai/fullsend/issues/159))
-- Agent authority modeling ([#877](https://github.com/fullsend-ai/fullsend/issues/877))
-- Separate permission profiles per run phase ([#2826](https://github.com/fullsend-ai/fullsend/issues/2826))
-- Privileged operations only in deterministic automation ([#2828](https://github.com/fullsend-ai/fullsend/issues/2828))
-
-### Human factors and governance
-
-As autonomous contribution scales, the organizational questions become unavoidable: domain ownership shifts, review fatigue, contributor motivation, and who has authority to make binding decisions about agent behavior.
-
-- Related: [human-factors](problems/human-factors.md), [governance](problems/governance.md), [contribution-volume](problems/contribution-volume.md)
-
-### Production feedback loops
-
-Closing the loop between production signals and what agents work on next. Platform organizations generate structured execution data that can drive triage and prioritization without waiting for humans to notice failures.
-
-- Related: [production-feedback](problems/production-feedback.md)
-
-### Agent attestations
-Cryptographic attestation of agent-produced artifacts, enabling consumers to verify what agent produced a change, under what policy, and with what inputs.
+| Deliverable | Outcome | Tracking |
+| ---------------------------------- | ------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Kubernetes and OpenShift execution | Forge-decoupled agent runtime | — |
+| Security hardening | Prompt injection, credentials, threat model | [fullsend#172](https://github.com/fullsend-ai/fullsend/issues/172) · [fullsend#174](https://github.com/fullsend-ai/fullsend/issues/174) · [fullsend#84](https://github.com/fullsend-ai/fullsend/issues/84) · [fullsend#159](https://github.com/fullsend-ai/fullsend/issues/159) · [fullsend#877](https://github.com/fullsend-ai/fullsend/issues/877) · [fullsend#2826](https://github.com/fullsend-ai/fullsend/issues/2826) · [fullsend#2828](https://github.com/fullsend-ai/fullsend/issues/2828) |
+| Human factors and governance | Ownership, review fatigue, contributor motivation | [human-factors](problems/human-factors.md) · [governance](problems/governance.md) |
+| Production feedback loops | Prod signals → triage / prioritization | [production-feedback](problems/production-feedback.md) |
+| Agent attestations | Cryptographic provenance for agent output | [fullsend#267](https://github.com/fullsend-ai/fullsend/issues/267) |
-- See [#267](https://github.com/fullsend-ai/fullsend/issues/267)
-## Foundation (April–May 2026)
+## July 2026 (done)
-Fullsend reached MVP in April 2026 and scaled through May. The platform can be installed at the org level, enroll repositories, and run a full autonomous SDLC loop: triage issues, produce code and tests, review PRs, apply fixes from review feedback, and file retrospective improvement proposals. The core agent suite ships as **default agents** and is designed to be general, extensible, and replaceable.
+July focused on adoption: public mint and Cloudflare deploy paths, forge-aware repo management, layered config, BYOA/CEL docs, and GitLab polling foundations — plus agent-side review/eval/docs work in [fullsend-ai/agents](https://github.com/fullsend-ai/agents).
-What this phase established:
+Links use `/issues/N` (GitHub serves merged PRs there too) so previews don’t try to load a PR diff.
-- **Sandboxed runner architecture** — agents execute in isolated environments with controlled access to forge credentials and repository content
-- **Default agent suite** — default agents that enable an end-to-end bugfix workflow: triage, code, review, fix, and retro
-- **Binary autonomy model** — per-repo opt-in, CODEOWNERS enforcing human approval on protected paths
-- **The repo is the coordinator** — branch protection, CODEOWNERS, and status checks replace a coordinator agent
-- **Trust derives from repository permissions, not agent identity**
-- **Fullsend is using fullsend** — the platform dogfoods its own agent workflows
-- **20+ Konflux repositories** running fullsend for bug triage, code production, and review
+- **Cloudflare / public mint** — Worker mint path, WASM host bridge, and deploy platform mode ([fullsend#5427](https://github.com/fullsend-ai/fullsend/issues/5427), [fullsend#5447](https://github.com/fullsend-ai/fullsend/issues/5447), [fullsend#5615](https://github.com/fullsend-ai/fullsend/issues/5615)); mint privilege ADRs ([fullsend#5328](https://github.com/fullsend-ai/fullsend/issues/5328))
+- **Repos management** — forge-aware `repos`, mixed-forge manifests, upgrade mint checks, docs ([fullsend#5617](https://github.com/fullsend-ai/fullsend/issues/5617), [fullsend#5623](https://github.com/fullsend-ai/fullsend/issues/5623), [fullsend#5643](https://github.com/fullsend-ai/fullsend/issues/5643), [fullsend#5600](https://github.com/fullsend-ai/fullsend/issues/5600), [fullsend#5602](https://github.com/fullsend-ai/fullsend/issues/5602))
+- **Layered configuration** — `config.base.yaml` + parent fallback; merge semantics docs ([fullsend#5652](https://github.com/fullsend-ai/fullsend/issues/5652), [fullsend#5625](https://github.com/fullsend-ai/fullsend/issues/5625), [fullsend#5651](https://github.com/fullsend-ai/fullsend/issues/5651))
+- **BYOA / harness** — agent files out of scaffold embed; CEL trigger guidance ([fullsend#5588](https://github.com/fullsend-ai/fullsend/issues/5588), [fullsend#5532](https://github.com/fullsend-ai/fullsend/issues/5532), [fullsend#5404](https://github.com/fullsend-ai/fullsend/issues/5404))
+- **GitLab polling** — client polling + cron-polling event router ([fullsend#5391](https://github.com/fullsend-ai/fullsend/issues/5391))
+- **Telemetry** — OTEL env forwarding to managed agents ([fullsend#5531](https://github.com/fullsend-ai/fullsend/issues/5531))
+- **Security docs** — `SECURITY.md`; destructive forge ops guidance ([fullsend#5635](https://github.com/fullsend-ai/fullsend/issues/5635), [fullsend#5587](https://github.com/fullsend-ai/fullsend/issues/5587))
+- **Behaviour testing** — forge constraints docs; URL harness scenarios; pool/cleanup ([fullsend#5546](https://github.com/fullsend-ai/fullsend/issues/5546), [fullsend#5407](https://github.com/fullsend-ai/fullsend/issues/5407), [fullsend#5444](https://github.com/fullsend-ai/fullsend/issues/5444))
+- **Agents: review / fix loop** — scoped re-review dispatch; two-pass large-PR review ([agents#355](https://github.com/fullsend-ai/agents/issues/355), [agents#190](https://github.com/fullsend-ai/agents/issues/190))
+- **Agents: evals** — fix-agent `/fs-fix` functional eval ([agents#381](https://github.com/fullsend-ai/agents/issues/381))
+- **Agents: triage** — in-progress action; skip code agent on workflow-file-only changes ([agents#434](https://github.com/fullsend-ai/agents/issues/434), [agents#326](https://github.com/fullsend-ai/agents/issues/326))
diff --git a/website/.vitepress/config.ts b/website/.vitepress/config.ts
index 3a5214a018..948e14df00 100644
--- a/website/.vitepress/config.ts
+++ b/website/.vitepress/config.ts
@@ -286,6 +286,7 @@ export default defineConfig({
items: getMarkdownFiles("contributing", "contributing"),
},
{ text: "Roadmap", link: "/roadmap" },
+ { text: "Archived roadmaps", link: "/archived-roadmap" },
{ text: "Landscape", link: "/landscape" },
{
text: "Architecture Decisions",