fullsend-ai · ralphbean · May 28, 2026
diff --git a/README.md b/README.md
@@ -67,7 +67,7 @@ If you're applying fullsend to your own organization, consider adding your speci
 | A question, bug, or small suggestion | **File an issue** — lowest friction, can graduate later. |
 | A new problem area no existing doc covers | **Create a problem doc** in `docs/problems/` and link it here. |
 | More to say about an existing problem area | **Expand the existing problem doc.** |
-| A specific decision that needs a yes-or-no answer | **Propose an ADR** in `docs/ADRs/` — even with only one option, file it as `Undecided` ([see ADR 0001](docs/ADRs/0001-use-adrs-for-decision-making.md)). |
+| A specific decision that needs a yes-or-no answer | **Propose an ADR** in `docs/ADRs/` via a pull request ([see ADR 0001](docs/ADRs/0001-use-adrs-for-decision-making.md)). |
 
 When in doubt, start with an issue.
 

diff --git a/docs/ADRs/0000-adr-template.md b/docs/ADRs/0000-adr-template.md
@@ -1,6 +1,6 @@
 ---
 title: "NUMBER. TITLE"
-status: Proposed  # Valid values: Proposed, Undecided, Accepted, Deprecated, Superseded
+status: Accepted  # Valid values: Accepted, Deprecated, Superseded
 relates_to:
   - problem-doc-name  # filename without .md from docs/problems/
 topics:
@@ -13,7 +13,7 @@ Date: YYYY-MM-DD
 
 ## Status
 
-{Proposed | Undecided | Accepted | Deprecated | Superseded}
+{Accepted | Deprecated | Superseded}
 
 <!-- Once this ADR is Accepted, its content is frozen. Do not edit the Context,
      Decision, or Consequences sections. If circumstances change, write a new
@@ -27,18 +27,13 @@ What is the issue that we're seeing that motivates this decision or change?
 ## Options
 
 _Optional. Include only when there are genuine alternatives worth documenting.
-For Undecided ADRs, describe the options under consideration without choosing
-one yet. For Proposed or Accepted ADRs, include only if the rejected
-alternatives add useful context. If the decision is obvious, skip this
-section._
+For Accepted ADRs, include only if the rejected alternatives add useful
+context. If the decision is obvious, skip this section._
 
 ## Decision
 
-_Leave blank for Undecided ADRs._ What is the change that we're proposing
-and/or doing?
+What is the change that we're proposing and/or doing?
 
 ## Consequences
 
 What becomes easier or more difficult to do because of this change?
-For Undecided ADRs, describe consequences that apply regardless of which option
-is chosen, or leave blank.
diff --git a/docs/ADRs/0001-use-adrs-for-decision-making.md b/docs/ADRs/0001-use-adrs-for-decision-making.md
@@ -41,21 +41,10 @@ ADRs live in `docs/ADRs/` and follow the naming convention
 
 Each ADR has a Status field. Valid statuses are:
 
-- **Proposed** -- A decision has been drafted but not yet discussed or agreed
-  upon.
-- **Undecided** -- The problem is identified, options are described, but no
-  decision has been made yet. These ADRs can be merged and iterated on. They
-  must include an Options section describing the alternatives under
-  consideration.
 - **Accepted** -- The decision has been made.
 - **Deprecated** -- The decision is no longer relevant.
 - **Superseded** -- The decision has been replaced by a later ADR.
 
-The Undecided status is a deliberate part of our workflow. It lets us merge ADRs
-that frame a decision and its options, so the community can discuss and refine
-the options over time without pressure to decide prematurely. When consensus
-forms, the ADR is updated to Accepted with a Decision section filled in.
-
 Each ADR includes YAML frontmatter with structured metadata:
 
 - **title** -- The ADR title (required).
@@ -77,8 +66,7 @@ runs in CI to validate statuses, number uniqueness, and frontmatter correctness
 
 - Problem documents in `docs/problems/` remain the place for open-ended
   exploration. ADRs are for when a specific decision point has been identified.
-- Contributors can propose ADRs in the Undecided state to start structured
-  discussion around a specific choice.
+- Contributors propose ADRs via pull requests for discussion before merging.
 - The linting ensures ADRs follow the expected format, catching mistakes early.
 - We inherit a proven format from the broader konflux-ci organization, making it
   familiar to contributors who work across repos.
diff --git a/docs/ADRs/0002-initial-fullsend-design.md b/docs/ADRs/0002-initial-fullsend-design.md
@@ -1,6 +1,6 @@
 ---
 title: "2. Initial Fullsend Design"
-status: Proposed
+status: Accepted
 relates_to:
   - agent-architecture
   - autonomy-spectrum
@@ -21,7 +21,7 @@ Date: 2026-03-23
 
 ## Status
 
-Proposed
+Accepted
 
 ## Context
 

diff --git a/docs/ADRs/0003-org-config-repo-convention.md b/docs/ADRs/0003-org-config-repo-convention.md
@@ -1,6 +1,6 @@
 ---
 title: "3. Org-level configuration lives in a conventional repo"
-status: Proposed
+status: Accepted
 relates_to:
   - governance
   - codebase-context
@@ -20,7 +20,7 @@ Date: 2026-03-25
 
 ## Status
 
-Proposed
+Accepted
 
 ## Context
 

diff --git a/docs/ADRs/0016-unidirectional-control-flow.md b/docs/ADRs/0016-unidirectional-control-flow.md
@@ -1,6 +1,6 @@
 ---
 title: "16. Unidirectional control flow through the execution stack"
-status: Proposed
+status: Accepted
 relates_to:
   - agent-architecture
   - agent-infrastructure
@@ -17,7 +17,7 @@ Date: 2026-03-27
 
 ## Status
 
-Proposed
+Accepted
 
 ## Context
 

diff --git a/docs/ADRs/0018-scripted-pipeline-for-multi-agent-orchestration.md b/docs/ADRs/0018-scripted-pipeline-for-multi-agent-orchestration.md
@@ -1,6 +1,6 @@
 ---
 title: "18. Scripted pipeline for multi-agent orchestration"
-status: Proposed
+status: Accepted
 relates_to:
   - agent-architecture
   - agent-infrastructure
@@ -16,7 +16,7 @@ Date: 2026-04-08
 
 ## Status
 
-Proposed
+Accepted
 
 <!-- Once this ADR is Accepted, its content is frozen. Do not edit the Context,
      Decision, or Consequences sections. If circumstances change, write a new

diff --git a/docs/ADRs/0027-allowed-and-disallowed-tools-for-agents.md b/docs/ADRs/0027-allowed-and-disallowed-tools-for-agents.md
@@ -1,6 +1,6 @@
 ---
 title: "27. Allowed and Disallowed Tools for Agents"
-status: Proposed
+status: Accepted
 relates_to:
   - agent-architecture
   - security-threat-model
@@ -16,7 +16,7 @@ Date: 2026-04-21
 
 ## Status
 
-Proposed
+Accepted
 
 ## Context
 

diff --git a/docs/ADRs/0031-reusable-workflows-for-action-installed-distribution.md b/docs/ADRs/0031-reusable-workflows-for-action-installed-distribution.md
@@ -1,6 +1,6 @@
 ---
 title: "31. Reusable workflows for action-installed distribution"
-status: Proposed
+status: Accepted
 relates_to:
   - agent-infrastructure
 topics:
@@ -16,7 +16,7 @@ Date: 2026-05-06
 
 ## Status
 
-Proposed
+Accepted
 
 ## Context
 

diff --git a/docs/ADRs/0032-safe-push-wrapper-for-sandboxed-agents.md b/docs/ADRs/0032-safe-push-wrapper-for-sandboxed-agents.md
@@ -1,6 +1,6 @@
 ---
 title: "32. safe-push wrapper binary for sandboxed agents"
-status: Proposed
+status: Accepted
 relates_to:
   - agent-architecture
   - agent-infrastructure
@@ -19,7 +19,7 @@ Date: 2026-05-07
 
 ## Status
 
-Proposed (extends [ADR 0025](0025-provider-credential-delivery-for-sandboxed-agents.md))
+Accepted (extends [ADR 0025](0025-provider-credential-delivery-for-sandboxed-agents.md))
 
 ## Context
 

diff --git a/docs/ADRs/0034-centralized-shim-routing-via-dispatch.md b/docs/ADRs/0034-centralized-shim-routing-via-dispatch.md
@@ -1,6 +1,6 @@
 ---
 title: "34. Centralized shim routing via dispatch.yml"
-status: Proposed
+status: Accepted
 relates_to:
   - agent-infrastructure
 topics:
@@ -16,7 +16,7 @@ Date: 2026-05-07
 
 ## Status
 
-Proposed
+Accepted
 
 ## Context
 

diff --git a/docs/ADRs/0035-layered-content-resolution.md b/docs/ADRs/0035-layered-content-resolution.md
@@ -1,6 +1,6 @@
 ---
 title: "35. Layered content resolution"
-status: Proposed
+status: Accepted
 relates_to:
   - agent-infrastructure
   - agent-architecture
@@ -17,7 +17,7 @@ Date: 2026-05-09
 
 ## Status
 
-Proposed
+Accepted
 
 ## Context
 

diff --git a/docs/ADRs/0036-agent-execution-sandbox.md b/docs/ADRs/0036-agent-execution-sandbox.md
@@ -1,6 +1,6 @@
 ---
 title: "36. Agent Execution Sandbox Architecture"
-status: Proposed
+status: Accepted
 relates_to:
   - agent-infrastructure
 topics:
@@ -17,7 +17,7 @@ Date: 2026-05-05
 
 ## Status
 
-Proposed
+Accepted
 
 ## Context
 

diff --git a/docs/ADRs/0038-universal-harness-access.md b/docs/ADRs/0038-universal-harness-access.md
@@ -1,6 +1,6 @@
 ---
 title: "38. Universal harness access via URLs and paths"
-status: Proposed
+status: Accepted
 relates_to:
   - agent-architecture
   - security-threat-model
@@ -20,7 +20,7 @@ Date: 2026-05-07
 
 ## Status
 
-Proposed
+Accepted
 
 ## Context
 

diff --git a/docs/plans/agent-execution-environment.md b/docs/plans/agent-execution-environment.md
@@ -2,7 +2,7 @@
 
 How do fullsend agents execute on CI runners, what does the sandbox environment contain, and how does it work across GitHub Actions and GitLab CI?
 
-**Note:** This is an implementation plan companion to [ADR-0036](../ADRs/0036-agent-execution-sandbox.md). It provides detailed implementation guidance for the chosen sandbox architecture, structured for iterative evolution as the design is validated in production. Once the architecture stabilizes and moves from "Proposed" to "Accepted", operational content may migrate to `docs/guides/` per ADR-0023.
+**Note:** This is an implementation plan companion to [ADR-0036](../ADRs/0036-agent-execution-sandbox.md). It provides detailed implementation guidance for the chosen sandbox architecture, structured for iterative evolution as the design is validated in production. Once the architecture stabilizes, operational content may migrate to `docs/guides/` per ADR-0023.
 
 ## Table of Contents
 

diff --git a/hack/lint-adr-frontmatter b/hack/lint-adr-frontmatter
@@ -25,7 +25,7 @@ REPO_ROOT = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))
 ADR_DIR = os.path.join(REPO_ROOT, "docs", "ADRs")
 PROBLEMS_DIR = os.path.join(REPO_ROOT, "docs", "problems")
 
-VALID_STATUSES = {"Proposed", "Undecided", "Accepted", "Deprecated", "Superseded"}
+VALID_STATUSES = {"Accepted", "Deprecated", "Superseded"}
 
 
 def get_valid_problem_docs():

diff --git a/hack/util/get-adr-status.sh b/hack/util/get-adr-status.sh
@@ -15,7 +15,7 @@
 
 set -euo pipefail
 
-VALID_STATUSES=("Proposed" "Undecided" "Accepted" "Deprecated" "Superseded")
+VALID_STATUSES=("Accepted" "Deprecated" "Superseded")
 
 error() {
     echo "ERROR: $1" >&2

diff --git a/skills/writing-adrs/SKILL.md b/skills/writing-adrs/SKILL.md
@@ -47,7 +47,7 @@ understand what is true *now*, without tracing a chain of ADRs.
 ## When to Use
 
 - A specific decision has emerged from discussion in a problem doc
-- You need to frame an upcoming decision (Undecided status)
+- You need to frame an upcoming decision
 - An ADR has been accepted and living documents need updating
 
 Do NOT use for open-ended exploration -- that belongs in problem docs.
@@ -124,9 +124,8 @@ Follow these steps in order:
    the `title` field and the `# heading` must have **no leading zeros**
    (e.g., `"1. Use ADRs"`, not `"0001. Use ADRs"`). The four-digit
    zero-padded format is only for filenames.
-4. **Choose the right status.** Use **Proposed** for a draft awaiting
-   discussion. Use **Undecided** when the problem is identified but no choice
-   has been made. Use **Accepted** when the decision is made. Include an
+4. **Choose the right status.** Use **Accepted** when the decision is made.
+   Use **Deprecated** or **Superseded** when retiring an ADR. Include an
    Options section only when there are genuine alternatives worth documenting;
    if the decision is obvious, just decide it.
 5. **Write the ADR.** Follow the conciseness rules above.