docs(#3862): remove ADR links from user-facing documentation

docs/guides/getting-started/repo-management.md

@@ -364,9 +364,8 @@ command is primarily useful for one-off checks.
 
 ## Migrating from per-org mode to manifest management
 
-Organizations migrating from per-org mode
-([ADR 0044](../../ADRs/0044-deprecate-per-org-installation-mode.md)) to
-per-repo manifest management can use the following workflow.
+Organizations migrating from per-org mode to per-repo manifest management
+can use the following workflow.
 
 ### Step 1: Generate a manifest from existing installations
 
@@ -466,4 +465,3 @@ commands.
 - [Per-Org Mode](org-mode.md) — Organization-mode installation (planned deprecation)
 - [CLI Reference: fullsend repos](../../cli/repos.md) — Full flag and subcommand reference
 - [Mint administration](../infrastructure/mint-administration.md) — Token mint deployment and management
-- [ADR 0057](../../ADRs/0057-repos-management.md) — Design decision for repos management

docs/guides/infrastructure/advanced-setup.md

@@ -27,7 +27,7 @@ If the platform operator also provides a pre-existing WIF provider, skip `infere
 
 If you have IAM access to the platform operator's GCP project, pass `--mint-project` and `--mint-region` to `github setup` to enable auto-discovery of shared app IDs and automatic validation of mint configuration. This requires `roles/cloudfunctions.developer` on the platform mint project.
 
-> This section documents the **SaaS installation profile** defined in [ADR 0033 §6](../../ADRs/0033-per-repo-installation-mode.md#6-credential-models). See the [CLI reference](../../cli/github.md#flags) for the full flag list.
+> This section documents the **SaaS installation profile** — the default variant of the Managed model, where a platform operator pre-provisions the shared GitHub Apps and mint for you. See the [CLI reference](../../cli/github.md#flags) for the full flag list.
 
 ## OAuth scope reference
 

docs/guides/infrastructure/distributed-tracing.md

@@ -3,8 +3,6 @@
 Fullsend produces structured telemetry for every agent run. This guide covers
 how to configure, consume, and extend the tracing system.
 
-Decided in [ADR 0050](../../ADRs/0050-distributed-tracing-instrumentation.md).
-
 ## Zero-configuration baseline (Level 1)
 
 Every `fullsend run` produces one file in the run output directory with no
@@ -110,8 +108,7 @@ export OTEL_EXPORTER_OTLP_TRACES_HEADERS="authorization=Basic%20${CREDS_B64},x-m
 ## Enabling content capture (Level 3)
 
 > **Planned:** Level 3 content capture is not yet implemented. This section
-> documents the contract decided in
-> [ADR 0050](../../ADRs/0050-distributed-tracing-instrumentation.md).
+> documents the telemetry contract.
 
 By default, spans contain metadata only (timing, token counts, tool names,
 errors). To include full prompt/completion content in spans:

docs/guides/infrastructure/infrastructure-reference.md

@@ -92,7 +92,7 @@ Custom roles can be registered via the standalone mint's `CUSTOM_ROLE_PERMISSION
 
 ### Mint Security Controls
 
-Mode is inferred from `ALLOWED_ORGS` — there is no separate trust-mode flag. See [ADR 0059](../../ADRs/0059-public-mint-mode-with-wildcard-allowlists.md) for the full decision.
+Mode is inferred from `ALLOWED_ORGS` — there is no separate trust-mode flag.
 
 **Tight mint** (default): explicit comma-separated org list (no `*`).
 

docs/guides/infrastructure/mint-administration.md

@@ -109,7 +109,7 @@ The deploy command automatically detects when the deployed function is up-to-dat
 
 ### Public mint deployment
 
-Use `--public` to bootstrap a public mint ([ADR 0059](../../ADRs/0059-public-mint-mode-with-wildcard-allowlists.md)): `ALLOWED_ORGS=*` on the Cloud Function and a permissive WIF provider CEL for the STS authentication path. Orgs call the mint via upstream reusable workflows in `fullsend-ai/fullsend` after installing the shared public GitHub Apps — `mint enroll` is not required.
+Use `--public` to bootstrap a public mint: `ALLOWED_ORGS=*` on the Cloud Function and a permissive WIF provider CEL for the STS authentication path. Orgs call the mint via upstream reusable workflows in `fullsend-ai/fullsend` after installing the shared public GitHub Apps — `mint enroll` is not required.
 
 ```bash
 fullsend mint deploy --project="$GCP_PROJECT" --pem-dir=/path/to/pems --public
@@ -277,7 +277,7 @@ Role PEM secrets and `ROLE_APP_IDS` must already exist on the mint, created duri
 
 ### Public mint mode
 
-When the mint is configured with `ALLOWED_ORGS=*` ([ADR 0059](../../ADRs/0059-public-mint-mode-with-wildcard-allowlists.md)), `mint enroll` exits successfully (exit code 0) in both public and tight modes, but only tight mode updates `ALLOWED_ORGS` and WIF. In public mode, org registration is unnecessary because all orgs are already allowed — the command discovers the mint and reports public mode without changing configuration. Scripts can call enroll in both modes without branching. `mint enroll owner/repo` also succeeds without per-repo WIF changes; per-repo installs use the default WIF provider and upstream reusable workflows.
+When the mint is configured with `ALLOWED_ORGS=*` (public mode), `mint enroll` exits successfully (exit code 0) in both public and tight modes, but only tight mode updates `ALLOWED_ORGS` and WIF. In public mode, org registration is unnecessary because all orgs are already allowed — the command discovers the mint and reports public mode without changing configuration. Scripts can call enroll in both modes without branching. `mint enroll owner/repo` also succeeds without per-repo WIF changes; per-repo installs use the default WIF provider and upstream reusable workflows.
 
 `mint unenroll` cannot remove individual orgs from a public mint. To restrict access, replace `ALLOWED_ORGS=*` with an explicit org list (config-only rollback; no PEM rotation required).
 

docs/guides/infrastructure/private-repositories.md

@@ -167,7 +167,7 @@ Check the GitHub Actions logs for agent runs in both the target repo and `.fulls
 - Do log outputs contain sensitive values from the private repo?
 - Are the harness-level [secret redaction](../user/customizing-agents.md#harness-yaml-structure) and output scanning working as expected?
 
-> **Note:** Agent output goes through the harness-level `SecretRedactor` pipeline before being applied (see [ADR 0022](../../ADRs/0022-harness-level-output-schema-enforcement.md)). This catches known secret patterns but cannot catch all forms of sensitive content — `AGENTS.md` instructions are your primary defense for context-specific information.
+> **Note:** Agent output goes through the harness-level `SecretRedactor` pipeline before being applied. This catches known secret patterns but cannot catch all forms of sensitive content — `AGENTS.md` instructions are your primary defense for context-specific information.
 
 ## What should not be deployed based on data sensitivity
 

docs/guides/infrastructure/standalone-mint.md

@@ -120,7 +120,7 @@ The standalone mint is configured entirely through environment variables:
 
 ### Public mint mode
 
-Set `ALLOWED_ORGS=*` to enable public mint mode ([ADR 0059](../../ADRs/0059-public-mint-mode-with-wildcard-allowlists.md)):
+Set `ALLOWED_ORGS=*` to enable public mint mode:
 
 - Any org may request tokens (installation lookup still scopes tokens to the requesting org)
 - `job_workflow_ref` must reference `fullsend-ai/fullsend/.github/workflows/` only

docs/guides/user/bring-your-own-agent.md

@@ -21,7 +21,7 @@ GitHub event (issue opened, label added, PR comment, ...)
         ▼
 ┌── fullsend dispatch ──────────────────┐
 │  1. Normalize event → NormalizedEvent │
-│  2. Authorize (ADR 0054)              │
+│  2. Authorize                         │
 │  3. Enumerate registered harnesses    │
 │  4. Evaluate CEL triggers             │
 │  5. Launch matching agents            │
@@ -42,7 +42,7 @@ You do not need to write a GitHub Actions workflow file for each custom agent. T
 
 For local development and debugging, you can also run an agent directly with `fullsend run my-agent` — see [Testing locally](#testing-locally).
 
-**Security model:** agents run inside a sandboxed environment. The sandbox policy enforces filesystem access, landlock, and process identity. Network access is typically managed via **provider profiles** (YAML files in a `providers/` directory) referenced by name in the harness `providers:` list — the scaffold's shared `policies/base.yaml` contains no network rules, since built-in agents use providers ([ADR 0065](../../ADRs/0065-provider-backed-policy-composition.md)). Custom agents can also use inline `network_policies` in a per-agent policy file if providers don't cover their needs. Pre-scripts run on the trusted runner _before_ the sandbox starts; post-scripts run _after_ it exits.
+**Security model:** agents run inside a sandboxed environment. The sandbox policy enforces filesystem access, landlock, and process identity. Network access is typically managed via **provider profiles** (YAML files in a `providers/` directory) referenced by name in the harness `providers:` list — the scaffold's shared `policies/base.yaml` contains no network rules, since built-in agents use providers. Custom agents can also use inline `network_policies` in a per-agent policy file if providers don't cover their needs. Pre-scripts run on the trusted runner _before_ the sandbox starts; post-scripts run _after_ it exits.
 
 ## Minimum viable agent
 
@@ -126,7 +126,7 @@ Do NOT push code, create issues, or modify anything directly.
 Your only output is the JSON result file.
 ````
 
-Network access (which APIs the agent can reach) is controlled by provider profiles or inline `network_policies`. The six built-in profiles (`vertex-ai`, `github`, `github-ro`, `github-artifacts`, `gitleaks`, `package-registries`) use framework-known `type` values (e.g. `fullsend-vertex-ai`, `fullsend-github`). To define a fully custom provider type, reference a remote provider definition together with a matching `openshell.profiles` entry (see [Remote Providers and Profiles](customizing-agents.md#remote-providers-and-profiles) and [ADR 0070](../../ADRs/0070-portable-provider-profile-resolution.md)). For endpoints not covered by providers, inline `network_policies` in the policy YAML also work. Providers are the pattern used by fullsend's built-in agents ([ADR 0065](../../ADRs/0065-provider-backed-policy-composition.md)), but custom agents can use whichever approach fits.
+Network access (which APIs the agent can reach) is controlled by provider profiles or inline `network_policies`. The six built-in profiles (`vertex-ai`, `github`, `github-ro`, `github-artifacts`, `gitleaks`, `package-registries`) use framework-known `type` values (e.g. `fullsend-vertex-ai`, `fullsend-github`). To define a fully custom provider type, reference a remote provider definition together with a matching `openshell.profiles` entry (see [Remote Providers and Profiles](customizing-agents.md#remote-providers-and-profiles)). For endpoints not covered by providers, inline `network_policies` in the policy YAML also work. Providers are the pattern used by fullsend's built-in agents, but custom agents can use whichever approach fits.
 
 **Next steps:** [Register your agent](#registering-your-agent) so dispatch discovers it, then [write a CEL trigger](cel-triggers-reference.md#writing-cel-triggers) to control when it runs. To iterate on your agent locally before registering, see [Testing locally](#testing-locally).
 
@@ -212,7 +212,7 @@ image: ghcr.io/fullsend-ai/fullsend-sandbox:latest
 policy: policies/base.yaml          # Sandbox policy (filesystem, landlock, process)
 model: opus                         # LLM model override
 readonly_repo: false                # Mount repo as read-only in sandbox
-providers:                           # Network access via provider profiles (ADR 0065)
+providers:                           # Network access via provider profiles
   - vertex-ai                       # References providers/vertex-ai.yaml
   - github                          # References providers/github.yaml
 
@@ -535,7 +535,7 @@ repos:
 
 ## Migrating from `customized/`
 
-The `customized/` directory overlay ([ADR 0035](../../ADRs/0035-layered-content-resolution.md)) is deprecated in favor of the `base:` composition and config-driven registration described in this guide ([ADR 0064](../../ADRs/0064-deprecate-customized-directory-overlay.md)).
+The `customized/` directory overlay is deprecated in favor of the `base:` composition and config-driven registration described in this guide.
 
 If you have existing files in `customized/`, the `fullsend agent migrate-customizations` command automates the conversion to config-driven agents.
 

docs/guides/user/bugfix-workflow.md

@@ -11,7 +11,7 @@ When someone files a bug, fullsend's agent pipeline processes it through four st
 3. **Review** — multiple review agents evaluate the PR independently, a coordinator decides the outcome
 4. **Fix** — addresses review feedback automatically or on human command, then loops back to review
 
-Each stage is triggered by labels and can be restarted with slash commands. The pipeline uses GitHub's native primitives (issues, PRs, labels, branch protection) as its coordination layer — there is no central orchestrator. See [ADR 0002](../../ADRs/0002-initial-fullsend-design.md) for the full design.
+Each stage is triggered by labels and can be restarted with slash commands. The pipeline uses GitHub's native primitives (issues, PRs, labels, branch protection) as its coordination layer — there is no central orchestrator.
 
 ```
 Issue filed → Triage → ready-to-code → Code Agent → PR opened → Review → ready-for-merge → Merge
@@ -188,7 +188,6 @@ Fullsend does not lock you out. The labels are the state machine, and you have f
 
 ## Reference
 
-- [ADR 0002](../../ADRs/0002-initial-fullsend-design.md) — initial fullsend design (full workflow specification)
 - [Architecture overview](../../architecture.md) — component vocabulary and execution stack
 - [Installing fullsend](../getting-started/) — prerequisite: setup guide
 - [Security threat model](../../problems/security-threat-model.md) — how fullsend thinks about security

docs/guides/user/building-custom-agents.md

@@ -1,10 +1,11 @@
 # Building custom agents from scratch
 
 > **Deprecated:** This guide uses the `customized/` directory overlay, which is
-> deprecated per [ADR-0064](../../ADRs/0064-deprecate-customized-directory-overlay.md).
-> For new custom agents, register them in `config.yaml` with a local `source:`
-> path instead. Run `fullsend agent migrate-customizations --dry-run` to
-> preview migrating existing customizations.
+> deprecated. For new custom agents, register them in `config.yaml` with a
+> local `source:` path instead. See
+> [Bring Your Own Agent](bring-your-own-agent.md) for the recommended approach.
+> Run `fullsend agent migrate-customizations --dry-run` to preview migrating
+> existing customizations.
 
 This guide walks through creating a custom from-scratch agent on a per-repo
 fullsend installation.
@@ -177,7 +178,7 @@ env:
 
 timeout_minutes: 20
 
-# Optional: enable runtime skill fetching (ADR-0038 Phase 4)
+# Optional: enable runtime skill fetching
 # allowed_remote_resources:
 #   - https://github.com/org/skills/
 # allow_runtime_fetch: true
@@ -643,4 +644,3 @@ When creating a new agent, you need these files:
 - [Getting Started](../getting-started/README.md) — prerequisite: admin setup guide
 - [Architecture overview](../../architecture.md) — component vocabulary and execution stack
 - [Security threat model](../../problems/security-threat-model.md) — how fullsend thinks about security
-- [ADR 0035: Layered Content Resolution](../../ADRs/0035-layered-content-resolution.md) — how customized files override upstream defaults

docs/guides/user/cel-triggers-reference.md

@@ -12,9 +12,9 @@ When you register a custom agent and give it a `trigger` expression, fullsend ha
 
 2. **Normalize.** The `gha-event` input driver converts the raw GitHub event into a [`NormalizedEvent`](../../normative/normalized-event/v1/) — a forge-neutral struct with fields like `event.entity.kind`, `event.transition.kind`, and `event.actor.role`.
 
-3. **Authorize.** `fullsend dispatch` enforces the platform authorization gate ([ADR 0054](../../ADRs/0054-require-authorization-on-all-agent-dispatch-paths.md)) before any agent is considered. Authorization is a platform-level decision — your CEL trigger does not need to implement permission checks (though you can add guards like `event.actor.role` if your agent has stricter requirements).
+3. **Authorize.** `fullsend dispatch` enforces the platform authorization gate before any agent is considered. Authorization is a platform-level decision — your CEL trigger does not need to implement permission checks (though you can add guards like `event.actor.role` if your agent has stricter requirements).
 
-4. **Enumerate.** Dispatch loads all registered agents from the merged config (`agents:` list in org and per-repo `config.yaml`, plus scaffold discovery from [ADR 0058](../../ADRs/0058-agent-registration.md)). Each harness with a non-empty `trigger` field is a candidate.
+4. **Enumerate.** Dispatch loads all registered agents from the merged config (`agents:` list in org and per-repo `config.yaml`, plus scaffold discovery). Each harness with a non-empty `trigger` field is a candidate.
 
 5. **Evaluate.** Each candidate's CEL `trigger` expression is evaluated with `event` bound to the `NormalizedEvent`. Every harness whose trigger returns `true` is selected. Multiple agents can match the same event (parallel fan-out).