docs(adr): add ADR 0068 for ready-made configuration presets

[ifireball]

Summary

• Add ADR deciding that per-repo installation settings (mint URL, inference backend, etc.) move into layered .fullsend/config.base.yaml and .fullsend/config.yaml files resolved via accessor methods.
• Add fullsend github setup --config <path-or-url> for installing vendor presets, dropping per-adopter mint and inference enrollment when shared infrastructure trusts job_workflow_ref to upstream workflows.
• Update docs/architecture.md and annotate the bootstrap open question in docs/problems/governance.md.

Made with Cursor

[fullsend-ai-review]

🤖 Review · ⚠️ Cancelled · Started 8:10 AM UTC · Ended 8:13 AM UTC
Commit: ea2ca95 · View workflow run →

[github-actions]

Site preview

Preview: https://e39ffcf0-site.fullsend-ai.workers.dev

Commit: 419d3322b3f9b448ea2b8f1bfbd6596e15944032

[fullsend-ai-review]

🤖 Review · ⚠️ Cancelled · Started 8:16 AM UTC · Ended 8:16 AM UTC
Commit: ea2ca95 · View workflow run →

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 8:19 AM UTC · Completed 8:32 AM UTC
Commit: 5a64538 · View workflow run →

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[fullsend-ai-review]

Review

Re-review note: One commit since the prior review (3784eee) makes inference authorization language mechanism-neutral in ADR 0068: Decision 4 now separates mint (decided via ADR 0059) from inference (explicitly undecided), the Context section lists multiple possible authorization models without presupposing one, and the Consequences section notes inference operator policy remains open. The architecture.md Decided bullet was updated accordingly. These are editorial improvements — well-executed, internally consistent, and introducing no new issues. No medium or higher findings.

Findings

Low

• [technical documentation accuracy] docs/ADRs/0068-ready-made-configuration-presets.md:41 — The sentence "[ADR 0064] deprecates the customized/ directory overlay; config.base.yaml is the successor mechanism for distributing a shared baseline" implies ADR 0064 establishes config.base.yaml as the successor. ADR 0064 actually names base: harness composition, URL references, and config-based agent registration as the successors — it does not mention config.base.yaml. The config.base.yaml concept is introduced by ADR 0068 itself. The semicolon creates ambiguity about whether the second clause is attributed to ADR 0064 or is a new statement.

• [contextual-placement] docs/architecture.md — The AGENTS.md layering paragraph still reads "The org's .fullsend/agents/ directory provides role-specific agent definitions that apply across all enrolled repos" immediately after the new paragraph explaining that per-repo installation replaces the middle tier. This creates a jarring transition where the new text describes deprecation of the org model while the existing text continues to describe it as current without qualification.

Previous run

Review

Re-review note: Changes since the prior review (e197021) refined ADR 0068 only: added ADR 0059/0057 cross-references, named --config-hash as an explicit flag, scoped Decision 1 to fullsend github setup, and differentiated mint (decided via ADR 0059) from inference (open follow-on). These are editorial improvements with no new issues. The merge of main introduced no content changes. No medium or higher findings.

Findings

Low

• [technical documentation accuracy] docs/ADRs/0068-ready-made-configuration-presets.md:38 — The sentence "[ADR 0064] deprecates the customized/ directory overlay; config.base.yaml is the successor mechanism for distributing a shared baseline" implies ADR 0064 establishes config.base.yaml as the successor. ADR 0064 actually names base: harness composition, URL references, and config-based agent registration as the successors — it does not mention config.base.yaml. The config.base.yaml concept is introduced by ADR 0068 itself. The semicolon creates ambiguity about whether the second clause is attributed to ADR 0064 or is a new statement.

• [contextual-placement] docs/architecture.md — The AGENTS.md layering paragraph still reads "The org's .fullsend/agents/ directory provides role-specific agent definitions that apply across all enrolled repos" immediately after the new paragraph explaining that per-repo installation replaces the middle tier. This creates a jarring transition where the new text describes deprecation of the org model while the existing text continues to describe it as current without qualification.

Previous run

Review

Re-review note: Changes since the prior review (e197021) refined ADR 0068 only: added ADR 0059/0057 cross-references, named --config-hash as an explicit flag, scoped Decision 1 to fullsend github setup, and differentiated mint (decided via ADR 0059) from inference (open follow-on). These are editorial improvements with no new issues. The merge of main introduced no content changes. No medium or higher findings.

Findings

Low

• [technical documentation accuracy] docs/ADRs/0068-ready-made-configuration-presets.md:38 — The sentence "[ADR 0064] deprecates the customized/ directory overlay; config.base.yaml is the successor mechanism for distributing a shared baseline" implies ADR 0064 establishes config.base.yaml as the successor. ADR 0064 actually names base: harness composition, URL references, and config-based agent registration as the successors — it does not mention config.base.yaml. The config.base.yaml concept is introduced by ADR 0068 itself. The semicolon creates ambiguity about whether the second clause is attributed to ADR 0064 or is a new statement.

• [contextual-placement] docs/architecture.md — The AGENTS.md layering paragraph still reads "The org's .fullsend/agents/ directory provides role-specific agent definitions that apply across all enrolled repos" immediately after the new paragraph explaining that per-repo installation replaces the middle tier. This creates a jarring transition where the new text describes deprecation of the org model while the existing text continues to describe it as current without qualification.

Previous run (2)

Review

Re-review note: Changes since the prior review (419d332) addressed both medium findings: (1) all five remaining org-level references in architecture.md (Agent Sandbox, Agent Harness, Policy Store, Intent Source, Agent Registry) have been updated to per-repo phrasing, resolving the internal consistency finding; and (2) the ADR 0068 Decided bullet now reads "will drop" with "(target state)" and notes enrollment remains required, resolving the documentation accuracy finding. No medium or higher findings remain.

Findings

Low

• [technical documentation accuracy] docs/ADRs/0068-ready-made-configuration-presets.md:38 — The sentence "[ADR 0064] deprecates the customized/ directory overlay; config.base.yaml is the successor mechanism for distributing a shared baseline" implies ADR 0064 establishes config.base.yaml as the successor. ADR 0064 actually names base: harness composition, URL references, and config-based agent registration as the successors — it does not mention config.base.yaml. The config.base.yaml concept is introduced by ADR 0068 itself. The semicolon creates ambiguity about whether the second clause is attributed to ADR 0064 or is a new statement.

• [contextual-placement] docs/architecture.md:394 — The AGENTS.md layering paragraph still reads "The org's .fullsend/agents/ directory provides role-specific agent definitions that apply across all enrolled repos" immediately after the new paragraph explaining that per-repo installation replaces the middle tier. This creates a jarring transition where the new text describes deprecation of the org model while the existing text continues to describe it as current without qualification.

Previous run (3)

Review

Re-review note: Changes since the prior review (419d332) addressed both medium findings: (1) all five remaining org-level references in architecture.md (Agent Sandbox, Agent Harness, Policy Store, Intent Source, Agent Registry) have been updated to per-repo phrasing, resolving the internal consistency finding; and (2) the ADR 0068 Decided bullet now reads "will drop" with "(target state)" and notes enrollment remains required, resolving the documentation accuracy finding. No medium or higher findings remain.

Findings

Low

• [technical documentation accuracy] docs/ADRs/0068-ready-made-configuration-presets.md:38 — The sentence "[ADR 0064] deprecates the customized/ directory overlay; config.base.yaml is the successor mechanism for distributing a shared baseline" implies ADR 0064 establishes config.base.yaml as the successor. ADR 0064 actually names base: harness composition, URL references, and config-based agent registration as the successors — it does not mention config.base.yaml. The config.base.yaml concept is introduced by ADR 0068 itself. The semicolon creates ambiguity about whether the second clause is attributed to ADR 0064 or is a new statement.

• [contextual-placement] docs/architecture.md:394 — The AGENTS.md layering paragraph still reads "The org's .fullsend/agents/ directory provides role-specific agent definitions that apply across all enrolled repos" immediately after the new paragraph explaining that per-repo installation replaces the middle tier. This creates a jarring transition where the new text describes deprecation of the org model while the existing text continues to describe it as current without qualification.

Previous run (4)

Review

Re-review note: Changes since the prior review (cf4542f) added a paragraph after the three-tier configuration diagram in architecture.md explaining the per-repo variant, which addresses the prior finding about the diagram not being updated. The remaining findings are about architecture.md editorial consistency — the same core issues from the prior review. Severity assessments anchored to the prior review where code is unchanged.

Findings

Medium

• [internal consistency] docs/architecture.md:36 — The diff replaces the Agent Infrastructure section's configuration reference with per-repo-only phrasing, while five other sections in the same document still reference the org-level .fullsend repository as the canonical configuration location: Agent Sandbox (~line 71), Agent Harness (~line 90), Policy Store (~line 211), Intent Source (~line 225), and Agent Registry (~line 260). The per-repo phrasing is correct per ADR 0044, but the partial update creates internal inconsistency within the document. Note: these org-level references were already stale before this PR (ADR 0044 was previously accepted), so the PR makes the inconsistency more visible rather than creating it.
  Remediation: Update the remaining five org-level references to match the per-repo model, or add deprecation annotations to each.

• [technical documentation accuracy] docs/architecture.md:51 — The new Decided bullet for ADR 0068 states "Shared-infrastructure presets drop per-adopter mint and inference enrollment in favor of job_workflow_ref trust to upstream workflows" without qualifying this as a target state. ADR 0068's own Decision 4 heading includes "(target state)" and its final paragraph explicitly states "Until those ADRs land, preset-based installs continue requiring that enrollment steps be performed." The architecture.md bullet omits both qualifiers, presenting the target state as decided current behavior.
  Remediation: Add a qualifier such as "(target state)" or "will drop" to the architecture.md bullet, or append a note that enrollment remains required until follow-on ADRs land.

Low

• [contextual-placement] docs/architecture.md — The new paragraph about per-repo installation replacing the middle tier is placed after the three-tier configuration diagram, which is contextually appropriate. However, the paragraph following it (about AGENTS.md layering) still references "The org's .fullsend/agents/ directory" without noting the deprecation, creating a jarring transition.

• [internal consistency] docs/ADRs/0068-ready-made-configuration-presets.md:101 — Decision 4's heading "Omit per-adopter mint and inference enrollment (target state)" now includes the "(target state)" qualifier, and the final paragraph clarifies enrollment is still required until follow-on ADRs land. The phased approach is communicated within the ADR itself.

• [implementation plan reference] docs/ADRs/0068-ready-made-configuration-presets.md — Several recent ADRs (0057, 0058, 0062) include Implementation or References sections linking to implementation plans. ADR 0068 describes substantial implementation work but does not reference an implementation plan.

• [missing-doc] docs/cli/github.md:43 — The fullsend github setup CLI reference does not list a --config flag. Expected since this is an ADR (not implementation PR), but should be tracked for the implementation PR.

Previous run (5)

Review

Re-review note: Changes since the prior review (cf4542f) added a paragraph after the three-tier configuration diagram in architecture.md explaining the per-repo variant, which addresses the prior finding about the diagram not being updated. The remaining findings are about architecture.md editorial consistency — the same core issues from the prior review. Severity assessments anchored to the prior review where code is unchanged.

Findings

Medium

• [internal consistency] docs/architecture.md:36 — The diff replaces the Agent Infrastructure section's configuration reference with per-repo-only phrasing, while five other sections in the same document still reference the org-level .fullsend repository as the canonical configuration location: Agent Sandbox (~line 71), Agent Harness (~line 90), Policy Store (~line 211), Intent Source (~line 225), and Agent Registry (~line 260). The per-repo phrasing is correct per ADR 0044, but the partial update creates internal inconsistency within the document. Note: these org-level references were already stale before this PR (ADR 0044 was previously accepted), so the PR makes the inconsistency more visible rather than creating it.
  Remediation: Update the remaining five org-level references to match the per-repo model, or add deprecation annotations to each.

• [technical documentation accuracy] docs/architecture.md:51 — The new Decided bullet for ADR 0068 states "Shared-infrastructure presets drop per-adopter mint and inference enrollment in favor of job_workflow_ref trust to upstream workflows" without qualifying this as a target state. ADR 0068's own Decision 4 heading includes "(target state)" and its final paragraph explicitly states "Until those ADRs land, preset-based installs continue requiring that enrollment steps be performed." The architecture.md bullet omits both qualifiers, presenting the target state as decided current behavior.
  Remediation: Add a qualifier such as "(target state)" or "will drop" to the architecture.md bullet, or append a note that enrollment remains required until follow-on ADRs land.

Low

• [contextual-placement] docs/architecture.md — The new paragraph about per-repo installation replacing the middle tier is placed after the three-tier configuration diagram, which is contextually appropriate. However, the paragraph following it (about AGENTS.md layering) still references "The org's .fullsend/agents/ directory" without noting the deprecation, creating a jarring transition.

• [internal consistency] docs/ADRs/0068-ready-made-configuration-presets.md:101 — Decision 4's heading "Omit per-adopter mint and inference enrollment (target state)" now includes the "(target state)" qualifier, and the final paragraph clarifies enrollment is still required until follow-on ADRs land. The phased approach is communicated within the ADR itself.

• [implementation plan reference] docs/ADRs/0068-ready-made-configuration-presets.md — Several recent ADRs (0057, 0058, 0062) include Implementation or References sections linking to implementation plans. ADR 0068 describes substantial implementation work but does not reference an implementation plan.

• [missing-doc] docs/cli/github.md:43 — The fullsend github setup CLI reference does not list a --config flag. Expected since this is an ADR (not implementation PR), but should be tracked for the implementation PR.

Previous run (6)

Review

Re-review note: Changes since the prior review (d788e89) are purely mechanical — renumbering ADR from 0063 to 0068 after 0063 was taken by polling-based-work-discovery, and merging main. ADR content is identical. Severity assessments anchored to the prior review.

The ADR itself is well-structured: it clearly describes the problem (flag sprawl and ephemeral provisioning), evaluates alternatives, and records four specific decisions with a coherent consequences section. The "Relationship to the three-tier model" paragraph (Decision 2) is a good addition that addresses prior review feedback about how config.base.yaml maps onto the existing configuration inheritance model. The governance.md annotation is precise — it marks the bootstrap open question as partially decided while noting what remains open.

The remaining findings are about docs/architecture.md internal consistency — the PR's edits to that document create a local inconsistency with unchanged passages that still describe the org .fullsend repository model.

Findings

Medium

• [internal consistency] docs/architecture.md:36 — The diff replaces the org-level .fullsend repository reference with per-repo-only phrasing ("each target repository's .fullsend/ directory"). However, per ADR 0033 section 8 ("Coexistence"), per-repo and per-org modes coexist within the same org. The rest of architecture.md (lines 67, 86, 207, 221, 256, and the three-tier diagram at lines 349–390) continues to reference the org .fullsend repository as a core concept. Replacing this line with per-repo-only phrasing creates an internal inconsistency.
  Remediation: Update line 36 to acknowledge both modes, e.g., "specified in the adopting organization's .fullsend repository ([ADR 0003]) or in each target repository's .fullsend/ directory ([ADR 0033])."

• [architectural-coherence] docs/ADRs/0068-ready-made-configuration-presets.md:64 — ADR 0068 introduces config.base.yaml as filling the org tier's configuration role in per-repo mode. The "Relationship to the three-tier model" paragraph (lines 64–77) explains this mapping, which is good. However, architecture.md's three-tier configuration diagram (lines 349–390) is not updated to reflect the per-repo variant where config.base.yaml replaces the org tier. A reader encountering the diagram would not know that per-repo mode uses a different layering.
  Remediation: Update architecture.md's three-tier diagram or add a note showing the per-repo variant where config.base.yaml replaces the org-tier config repo.

Low

• [internal consistency] docs/ADRs/0068-ready-made-configuration-presets.md:105 — Decision 4's heading ("Drop per-adopter mint and inference enrollment") and first paragraph describe the target state where enrollment is not needed, while the final paragraph states enrollment is still required until follow-on ADRs land. This reads as a phased approach, but the heading presents the target state as if it is the current decision. Consider clarifying the heading to distinguish the directional decision from the current interim requirement.

• [architectural model mismatch] docs/architecture.md:397 — The paragraph preceding the appended ADR 0068 reference discusses AGENTS.md layering and references the org's .fullsend/agents/ directory. The appended sentence about config.base.yaml introduces per-repo config layering into a paragraph about per-org agent definitions. Consider placing the ADR 0068 cross-reference in a more contextually appropriate location.

• [implementation plan reference] docs/ADRs/0068-ready-made-configuration-presets.md — Several recent ADRs (0057, 0058, 0062) include Implementation or References sections linking to implementation plans. ADR 0068 describes substantial implementation work (layered accessor API, preset URL handling) but does not reference an implementation plan.

• [Missing new identifier in CLI reference] docs/cli/github.md:43 — The fullsend github setup CLI reference does not list a --config flag. This is expected since the flag does not exist in code yet (this is an ADR, not an implementation PR), but should be tracked for the implementation PR.

Previous run (7)

Review

Findings

Medium

• [internal consistency] docs/architecture.md:36 — The diff replaces the org-level .fullsend repository reference with per-repo-only phrasing ("each target repository's .fullsend/ directory"). However, per ADR 0033 section 8 ("Coexistence"), per-repo and per-org modes coexist within the same org. The rest of architecture.md (lines 66, 80, 189, 203, 238, and the three-tier diagram at lines 348–368) continues to reference the org .fullsend repository as a core concept. Replacing this line with per-repo-only phrasing creates an internal inconsistency.
  Remediation: Update line 36 to acknowledge both modes, e.g., "specified in the adopting organization's .fullsend repository ([ADR 0003]) or in each target repository's .fullsend/ directory ([ADR 0033])."

• [architectural-coherence] docs/ADRs/0063-ready-made-configuration-presets.md:64 — ADR 0063 introduces config.base.yaml as filling the org tier's configuration role in per-repo mode. The "Relationship to the three-tier model" paragraph (lines 64–77) explains this mapping, which is good. However, architecture.md's three-tier configuration diagram (lines 336–371) is not updated to reflect the per-repo variant where config.base.yaml replaces the org tier. A reader encountering the diagram would not know that per-repo mode uses a different layering.
  Remediation: Update architecture.md's three-tier diagram or add a note showing the per-repo variant where config.base.yaml replaces the org-tier config repo.

Low

• [internal consistency] docs/ADRs/0063-ready-made-configuration-presets.md:105 — Decision 4's heading ("Drop per-adopter mint and inference enrollment") and first paragraph describe the target state where enrollment is not needed, while the final paragraph states enrollment is still required until follow-on ADRs land. This reads as a phased approach, but the heading presents the target state as if it is the current decision. Consider clarifying the heading to distinguish the directional decision from the current interim requirement.

• [architectural model mismatch] docs/architecture.md:377 — The paragraph preceding the appended ADR 0063 reference discusses AGENTS.md layering and references the org's .fullsend/agents/ directory. The appended sentence about config.base.yaml introduces per-repo config layering into a paragraph about per-org agent definitions. Consider placing the ADR 0063 cross-reference in a more contextually appropriate location.

• [implementation plan reference] docs/ADRs/0063-ready-made-configuration-presets.md — Several recent ADRs (0057, 0058, 0062) include Implementation or References sections linking to implementation plans. ADR 0063 describes substantial implementation work (layered accessor API, preset URL handling) but does not reference an implementation plan.

• [Missing new identifier in CLI reference] docs/cli/github.md:43 — The fullsend github setup CLI reference does not list a --config flag. This is expected since the flag does not exist in code yet (this is an ADR, not an implementation PR), but should be tracked for the implementation PR.

Previous run (8)

Review

Findings

Medium

• [internal consistency] docs/ADRs/0062-ready-made-configuration-presets.md:93 — Decision 4 is internally contradictory. The heading says "Drop per-adopter mint and inference enrollment from the install path." The first paragraph states the installer "does not run mint enrollment or inference WIF provisioning." The immediately following paragraph reverses this: "Until those ADRs land, preset-based installs continue requiring that enrollment steps be performed." ADR Decision sections record what is decided now. A reader cannot determine whether enrollment is currently required or not.
  Remediation: Reword Decision 4 to clearly separate the target state from the current transitional behavior. For example, title it "Target: drop per-adopter mint and inference enrollment" and lead with the transitional requirement, then state the end-state goal.

• [architectural model mismatch] docs/architecture.md:375 — The paragraph at line 375 references "The org's .fullsend/agents/ directory provides role-specific agent definitions that apply across all enrolled repos" — describing the per-org installation mode deprecated by ADR 0044. The PR appends ADR 0062 content about config.base.yaml to line 377 of this same paragraph, creating a block that mixes deprecated org-level concepts with new per-repo preset concepts. While the org-level reference is pre-existing, appending per-repo content without reconciling the surrounding text makes the paragraph contradictory.
  Remediation: Update lines 373–377 to remove or qualify the org-level .fullsend references, clarifying that in per-repo installation the config lives in each target repository's .fullsend/ directory.

Previous run (9)

Review

Findings

Medium

• [internal consistency] docs/ADRs/0059-ready-made-configuration-presets.md:96 — Decision 4 states that when a preset targets shared infrastructure, "the installer does not run mint enrollment or inference WIF provisioning." However, the immediately following paragraph contradicts this: "Until those ADRs land, preset-based installs continue requiring that enrollment steps be performed." The Decision section is the normative part of an ADR. Readers may interpret Decision 4's first paragraph as the current behavior rather than a future target state, since Decision sections typically record what is decided now, not aspirational end states.
  Remediation: Reword Decision 4 to clearly distinguish the target behavior from the current transitional behavior. For example: "When follow-on ADRs specify workflow pinning and backend policy, presets targeting shared infrastructure will not require per-adopter mint or inference enrollment. Until then, enrollment steps remain required even for preset-based installs."

Low

• [technical accuracy] docs/ADRs/0059-ready-made-configuration-presets.md:31 — The ADR states "The all-in-one fullsend admin install command is deprecated in favor of fullsend github setup." ADR 0044 deprecates the per-org installation mode (including admin install <org>), but admin install <owner/repo> for per-repo mode is not deprecated by ADR 0044. Meanwhile, docs/guides/dev/cli-internals.md does call admin install deprecated. The relationship between the two commands is unclear from this ADR's framing.
  Remediation: Clarify whether the statement refers to per-org admin install <org> specifically or to admin install generally.

• [edge case correctness] docs/ADRs/0059-ready-made-configuration-presets.md:87 — Decision 3 says the installer "validates fetched content against a content hash when provided" for preset URLs, but does not specify what happens when no hash is provided. This leaves the security posture ambiguous for implementers.

• [internal consistency] docs/architecture.md:370 — The diff adds a sentence describing config.base.yaml replacing the org-tier config. However, two lines above, the text still says "The org's .fullsend/agents/ directory provides role-specific agent definitions that apply across all enrolled repos" — referring to the per-org model that ADR 0044 has deprecated. While pre-existing, appending ADR 0059 content to a paragraph that still describes the deprecated model creates a contradictory paragraph.

• [missing-authorization] docs/ADRs/0059-ready-made-configuration-presets.md — ADR 0059 introduces a substantive architectural decision without a linked issue. Non-trivial architectural changes benefit from an issue establishing the problem space and providing traceability.

• [architectural-coherence] docs/ADRs/0059-ready-made-configuration-presets.md:69 — The ADR introduces a two-layer config model that coexists with the three-tier model from ADR 0003. The "Relationship to the three-tier model" paragraph explains the mapping but could better distinguish between configuration inheritance (ADR 0003's agent content) and configuration settings (this ADR's mint URL, inference backend).

• [incomplete-decision] docs/ADRs/0059-ready-made-configuration-presets.md:103 — Decision 4 defers critical security and trust decisions to follow-on ADRs. The current text makes it unclear whether this ADR authorizes implementation of decisions 1-3 independently, or is purely directional pending future ADRs.

Previous run (10)

Review

Findings

Medium

• [technical accuracy] docs/ADRs/0058-ready-made-configuration-presets.md:31 — The ADR states "The all-in-one fullsend admin install command is deprecated in favor of fullsend github setup." However, docs/reference/installation.md actively documents admin install as a primary installation path with no deprecation notice. If this ADR is recording an already-accepted deprecation, the claim is inconsistent with the current documentation. If the ADR is deciding the deprecation, that statement belongs in the Decision section, not the Context section.
  Remediation: Clarify whether admin install is already deprecated (and update installation docs accordingly) or whether this deprecation is a decision being made here (move the statement to the Decision section). If neither, rephrase to accurately describe the current relationship between admin install and github setup.

• [missing-authorization] docs/ADRs/0058-ready-made-configuration-presets.md — ADR addition with no linked issue. This introduces a substantive architectural decision (configuration presets, two-layer config model, --config flag, dropping per-adopter enrollment). While the ADR is self-contained and the PR description is clear, non-trivial changes benefit from an issue documenting the problem and authorizing the decision.
  Remediation: Consider linking an issue documenting the problem this ADR solves.

• [architectural-coherence-unclear] docs/ADRs/0058-ready-made-configuration-presets.md — The ADR introduces a two-layer config model (config.base.yaml / config.yaml) alongside the existing three-tier inheritance model from ADR 0003. The ADR includes a "Relationship to the three-tier model" paragraph explaining that config.base.yaml takes the org tier's place in per-repo installation and the lookup order is overlay → base → code defaults. However, it could be more explicit about whether this extends or supersedes ADR 0003, and under what installation modes each model applies.
  Remediation: Consider expanding the relationship paragraph to clarify whether this model supersedes ADR 0003 for per-repo installations or coexists alongside it.

---

Labels: PR adds an ADR covering configuration and installation, with doc updates to architecture.md and governance.md

Previous run (11)

Review

Findings

Medium

• [missing-authorization] docs/ADRs/0058-ready-made-configuration-presets.md — ADR addition with no linked issue. This introduces a substantive architectural decision (configuration presets, two-layer config model, --config flag, dropping per-adopter enrollment). While the ADR is self-contained and the PR is a draft, non-trivial changes benefit from an issue documenting the problem and authorizing the decision.
  Remediation: Consider linking an issue documenting the problem this ADR solves.

• [architectural-coherence-unclear] docs/ADRs/0058-ready-made-configuration-presets.md — The ADR introduces a two-layer config model (config.base.yaml / config.yaml) alongside the existing three-tier inheritance model (fullsend defaults < org .fullsend config < per-repo overrides) from ADR 0003. The ADR does include a "Relationship to the three-tier model" paragraph explaining that config.base.yaml takes the org tier's place in per-repo installation and the lookup order is overlay → base → code defaults. However, it could be more explicit about whether this extends or supersedes ADR 0003, and under what installation modes each model applies.
  Remediation: Consider expanding the relationship paragraph to clarify whether this model supersedes ADR 0003 for per-repo installations or coexists alongside it.

Previous run (12)

Review

Findings

High

• [missing-authorization] docs/ADRs/0058-ready-made-configuration-presets.md — Non-trivial ADR addition with no linked issue. This is a substantive architectural decision introducing a new configuration preset system, simplified installation flow, and two-layer configuration accessor model. Non-trivial changes require explicit authorization via a linked issue.
  Remediation: Create or link an issue documenting the problem this ADR solves and the authorization to proceed with this architectural decision.

Medium

• [internal-consistency] docs/ADRs/0058-ready-made-configuration-presets.md — The PR title says "add ADR 0056 for ready-made configuration presets" but the file is numbered 0058 and titled "58. Ready-made configuration presets". ADR 0056 already exists as docs/ADRs/0056-per-repo-precommit-tools-registry.md. The PR body also says "Add ADR 0056" but the file is 0058. The incorrect title will be confusing in commit history and PR search.
  Remediation: Update the PR title to reference ADR 0058, not 0056.

• [internal-consistency] docs/ADRs/0058-ready-made-configuration-presets.md:63 — ADR 0058 introduces a two-layer configuration model (config.base.yaml as vendor/base layer, config.yaml as user overlay) within the target repo's .fullsend/ directory. The existing docs/architecture.md "Configuration layering" section describes a three-tier inheritance model: upstream fullsend defaults < org .fullsend repo config < per-repo overrides. ADR 0058 does not explain how its two-layer base+overlay model relates to the existing three-tier model.
  Remediation: Add a paragraph to ADR 0058's Context or Decision section clarifying how the base+overlay configuration within a target repo's .fullsend/ directory maps onto the existing three-tier layering.

---

Labels: ADR addition covering installation configuration presets with documentation-only changes.

Previous run (13)

Review

Findings

Medium

• [internal consistency] docs/ADRs/0062-ready-made-configuration-presets.md:93 — Decision 4 is internally contradictory. The heading says "Drop per-adopter mint and inference enrollment from the install path." The first paragraph states the installer "does not run mint enrollment or inference WIF provisioning." The immediately following paragraph reverses this: "Until those ADRs land, preset-based installs continue requiring that enrollment steps be performed." ADR Decision sections record what is decided now. A reader cannot determine whether enrollment is currently required or not.
  Remediation: Reword Decision 4 to clearly separate the target state from the current transitional behavior. For example, title it "Target: drop per-adopter mint and inference enrollment" and lead with the transitional requirement, then state the end-state goal.

• [architectural model mismatch] docs/architecture.md:375 — The paragraph at line 375 references "The org's .fullsend/agents/ directory provides role-specific agent definitions that apply across all enrolled repos" — describing the per-org installation mode deprecated by ADR 0044. The PR appends ADR 0062 content about config.base.yaml to line 377 of this same paragraph, creating a block that mixes deprecated org-level concepts with new per-repo preset concepts. While the org-level reference is pre-existing, appending per-repo content without reconciling the surrounding text makes the paragraph contradictory.
  Remediation: Update lines 373–377 to remove or qualify the org-level .fullsend references, clarifying that in per-repo installation the config lives in each target repository's .fullsend/ directory.

Previous run (14)

Review

Findings

Medium

• [internal consistency] docs/ADRs/0059-ready-made-configuration-presets.md:96 — Decision 4 states that when a preset targets shared infrastructure, "the installer does not run mint enrollment or inference WIF provisioning." However, the immediately following paragraph contradicts this: "Until those ADRs land, preset-based installs continue requiring that enrollment steps be performed." The Decision section is the normative part of an ADR. Readers may interpret Decision 4's first paragraph as the current behavior rather than a future target state, since Decision sections typically record what is decided now, not aspirational end states.
  Remediation: Reword Decision 4 to clearly distinguish the target behavior from the current transitional behavior. For example: "When follow-on ADRs specify workflow pinning and backend policy, presets targeting shared infrastructure will not require per-adopter mint or inference enrollment. Until then, enrollment steps remain required even for preset-based installs."

Low

• [technical accuracy] docs/ADRs/0059-ready-made-configuration-presets.md:31 — The ADR states "The all-in-one fullsend admin install command is deprecated in favor of fullsend github setup." ADR 0044 deprecates the per-org installation mode (including admin install <org>), but admin install <owner/repo> for per-repo mode is not deprecated by ADR 0044. Meanwhile, docs/guides/dev/cli-internals.md does call admin install deprecated. The relationship between the two commands is unclear from this ADR's framing.
  Remediation: Clarify whether the statement refers to per-org admin install <org> specifically or to admin install generally.

• [edge case correctness] docs/ADRs/0059-ready-made-configuration-presets.md:87 — Decision 3 says the installer "validates fetched content against a content hash when provided" for preset URLs, but does not specify what happens when no hash is provided. This leaves the security posture ambiguous for implementers.

• [internal consistency] docs/architecture.md:370 — The diff adds a sentence describing config.base.yaml replacing the org-tier config. However, two lines above, the text still says "The org's .fullsend/agents/ directory provides role-specific agent definitions that apply across all enrolled repos" — referring to the per-org model that ADR 0044 has deprecated. While pre-existing, appending ADR 0059 content to a paragraph that still describes the deprecated model creates a contradictory paragraph.

• [missing-authorization] docs/ADRs/0059-ready-made-configuration-presets.md — ADR 0059 introduces a substantive architectural decision without a linked issue. Non-trivial architectural changes benefit from an issue establishing the problem space and providing traceability.

• [architectural-coherence] docs/ADRs/0059-ready-made-configuration-presets.md:69 — The ADR introduces a two-layer config model that coexists with the three-tier model from ADR 0003. The "Relationship to the three-tier model" paragraph explains the mapping but could better distinguish between configuration inheritance (ADR 0003's agent content) and configuration settings (this ADR's mint URL, inference backend).

• [incomplete-decision] docs/ADRs/0059-ready-made-configuration-presets.md:103 — Decision 4 defers critical security and trust decisions to follow-on ADRs. The current text makes it unclear whether this ADR authorizes implementation of decisions 1-3 independently, or is purely directional pending future ADRs.

Previous run (15)

Review

Findings

Medium

• [technical accuracy] docs/ADRs/0058-ready-made-configuration-presets.md:31 — The ADR states "The all-in-one fullsend admin install command is deprecated in favor of fullsend github setup." However, docs/reference/installation.md actively documents admin install as a primary installation path with no deprecation notice. If this ADR is recording an already-accepted deprecation, the claim is inconsistent with the current documentation. If the ADR is deciding the deprecation, that statement belongs in the Decision section, not the Context section.
  Remediation: Clarify whether admin install is already deprecated (and update installation docs accordingly) or whether this deprecation is a decision being made here (move the statement to the Decision section). If neither, rephrase to accurately describe the current relationship between admin install and github setup.

• [missing-authorization] docs/ADRs/0058-ready-made-configuration-presets.md — ADR addition with no linked issue. This introduces a substantive architectural decision (configuration presets, two-layer config model, --config flag, dropping per-adopter enrollment). While the ADR is self-contained and the PR description is clear, non-trivial changes benefit from an issue documenting the problem and authorizing the decision.
  Remediation: Consider linking an issue documenting the problem this ADR solves.

• [architectural-coherence-unclear] docs/ADRs/0058-ready-made-configuration-presets.md — The ADR introduces a two-layer config model (config.base.yaml / config.yaml) alongside the existing three-tier inheritance model from ADR 0003. The ADR includes a "Relationship to the three-tier model" paragraph explaining that config.base.yaml takes the org tier's place in per-repo installation and the lookup order is overlay → base → code defaults. However, it could be more explicit about whether this extends or supersedes ADR 0003, and under what installation modes each model applies.
  Remediation: Consider expanding the relationship paragraph to clarify whether this model supersedes ADR 0003 for per-repo installations or coexists alongside it.

---

Labels: PR adds an ADR covering configuration and installation, with doc updates to architecture.md and governance.md

Previous run (16)

Review

Findings

Medium

• [missing-authorization] docs/ADRs/0058-ready-made-configuration-presets.md — ADR addition with no linked issue. This introduces a substantive architectural decision (configuration presets, two-layer config model, --config flag, dropping per-adopter enrollment). While the ADR is self-contained and the PR is a draft, non-trivial changes benefit from an issue documenting the problem and authorizing the decision.
  Remediation: Consider linking an issue documenting the problem this ADR solves.

• [architectural-coherence-unclear] docs/ADRs/0058-ready-made-configuration-presets.md — The ADR introduces a two-layer config model (config.base.yaml / config.yaml) alongside the existing three-tier inheritance model (fullsend defaults < org .fullsend config < per-repo overrides) from ADR 0003. The ADR does include a "Relationship to the three-tier model" paragraph explaining that config.base.yaml takes the org tier's place in per-repo installation and the lookup order is overlay → base → code defaults. However, it could be more explicit about whether this extends or supersedes ADR 0003, and under what installation modes each model applies.
  Remediation: Consider expanding the relationship paragraph to clarify whether this model supersedes ADR 0003 for per-repo installations or coexists alongside it.

Previous run (17)

Review

Findings

High

• [missing-authorization] docs/ADRs/0058-ready-made-configuration-presets.md — Non-trivial ADR addition with no linked issue. This is a substantive architectural decision introducing a new configuration preset system, simplified installation flow, and two-layer configuration accessor model. Non-trivial changes require explicit authorization via a linked issue.
  Remediation: Create or link an issue documenting the problem this ADR solves and the authorization to proceed with this architectural decision.

Medium

• [internal-consistency] docs/ADRs/0058-ready-made-configuration-presets.md — The PR title says "add ADR 0056 for ready-made configuration presets" but the file is numbered 0058 and titled "58. Ready-made configuration presets". ADR 0056 already exists as docs/ADRs/0056-per-repo-precommit-tools-registry.md. The PR body also says "Add ADR 0056" but the file is 0058. The incorrect title will be confusing in commit history and PR search.
  Remediation: Update the PR title to reference ADR 0058, not 0056.

• [internal-consistency] docs/ADRs/0058-ready-made-configuration-presets.md:63 — ADR 0058 introduces a two-layer configuration model (config.base.yaml as vendor/base layer, config.yaml as user overlay) within the target repo's .fullsend/ directory. The existing docs/architecture.md "Configuration layering" section describes a three-tier inheritance model: upstream fullsend defaults < org .fullsend repo config < per-repo overrides. ADR 0058 does not explain how its two-layer base+overlay model relates to the existing three-tier model.
  Remediation: Add a paragraph to ADR 0058's Context or Decision section clarifying how the base+overlay configuration within a target repo's .fullsend/ directory maps onto the existing three-tier layering.

---

Labels: ADR addition covering installation configuration presets with documentation-only changes.

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 10:04 AM UTC · Completed 10:21 AM UTC
Commit: 9b813a4 · View workflow run →

[qodo-code-review]

PR Summary by Qodo

Add ADR 0058 for ready-made configuration presets
📝 Documentation 🕐 10-20 Minutes

Description

• Add ADR 0058 defining layered per-repo config via config.base.yaml + config.yaml accessors.
• Document preset-based installs via fullsend github setup --config .
• Update architecture/governance docs to reflect preset bootstrapping and remaining open questions.

Diagram

graph TD
  A["fullsend github setup"] --> B{{"Preset path/URL"}} --> C[".fullsend/config.base.yaml"] --> E["Config accessors"] --> H{{"job_workflow_ref trust"}} --> I["Mint/Inference backends"]
  A --> D[".fullsend/config.yaml"] --> E
  E --> G["Code defaults"]

Loading

High-Level Assessment

This PR is documentation-only and appropriately captures the decision in an ADR while updating the architecture/problem docs for consistency. The meaningful alternatives (flags-only vs monolithic config) are already evaluated inside ADR 0058; no additional architectural changes are needed in this PR beyond ensuring cross-links and numbering are correct.

Files changed (3) +124 / -2

Documentation (3) +124 / -2

0058-ready-made-configuration-presets.mdAdd ADR 0058 describing preset-based layered configuration +121/-0

Add ADR 0058 describing preset-based layered configuration

• Introduces an Accepted ADR specifying layered per-repo config ('.fullsend/config.base.yaml' + '.fullsend/config.yaml') resolved via accessor methods. Documents a 'fullsend github setup --config <path-or-url>' preset mechanism and the shift to workflow-ref trust instead of per-repo mint/inference enrollment for shared infrastructure presets.

docs/ADRs/0058-ready-made-configuration-presets.md

architecture.mdDocument ready-made config presets and per-repo layering semantics +2/-1

Document ready-made config presets and per-repo layering semantics

• Adds a new decided bullet describing preset-based installs and accessor-based config resolution. Updates the configuration layering section to clarify that 'config.base.yaml' replaces the org tier and that unset values still fall back to code defaults, referencing ADR 0058.

docs/architecture.md

governance.mdAnnotate bootstrap open question with ADR 0058 decision link +1/-1

Annotate bootstrap open question with ADR 0058 decision link

• Updates the bootstrap open question to reference the newly-decided preset-based install and config layering model, while noting that workflow pinning and backend policy are still unresolved.

docs/problems/governance.md

[fullsend-ai-review]

🤖 Review · ❌ Terminated · Started 10:41 AM UTC · Ended 10:53 AM UTC
Commit: ea2ca95 · View workflow run →

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📜 Skill insights (1)

Context used

✅ Compliance rules (platform): 51 rules

✅ Skills: writing-user-docs, writing-adrs

1. ADR 0058 exceeds 100 lines ✗ Dismissed 📜 Skill insight ⚙ Maintainability

Description

docs/ADRs/0058-ready-made-configuration-presets.md exceeds the 100-line maximum (excluding
frontmatter), increasing the chance the ADR is embedding too much design detail instead of linking
out to supporting docs. This violates the ADR size limit requirement.

Code

docs/ADRs/0058-ready-made-configuration-presets.md[R13-121]

+# 58. Ready-made configuration presets for simplified installation
+
+Date: 2026-06-29
+
+## Status
+
+Accepted
+
+## Context
+
+`fullsend github setup` today spreads installation decisions across many CLI
+flags (`--mint-url`, `--inference-project`, `--inference-region`, and others)
+and separate enrollment steps: operators run `fullsend mint enroll` to register
+repos with the token mint, and the installer provisions inference WIF
+infrastructure via the inference layer
+([ADR 0033](0033-per-repo-installation-mode.md),
+[ADR 0029](0029-central-token-mint-secretless-fullsend.md)). The all-in-one
+`fullsend admin install` command is deprecated in favor of `fullsend github
+setup`.
+
+Per-repo configuration lives in `.fullsend/config.yaml` within the target
+repository ([ADR 0033](0033-per-repo-installation-mode.md)), but key runtime
+settings (mint endpoint, inference backend) are only partially represented
+there; much of the effective configuration still comes from flags and ephemeral
+provisioning. That makes repeatable, vendor-curated installs harder than they
+need to be.
+
+[ADR 0029](0029-central-token-mint-secretless-fullsend.md) already treats
+`job_workflow_ref` as the trust binding for mint authorization. The same
+pattern can authorize inference backends without per-adopter enrollment, when
+the caller's workflow is pinned to definitions in `fullsend-ai/fullsend`.
+Concrete workflow pinning and backend policy are left to follow-on ADRs.
+
+## Options
+
+- **Flags only (status quo):** Flexible for advanced operators, but every
+  adopter must understand mint and inference provisioning details.
+- **Single monolithic `config.yaml`:** Simpler than flags, but mixes
+  vendor-provided defaults with repo-specific overrides and complicates upgrades
+  of the preset layer.
+
+## Decision
+
+**1. Move installation settings into configuration files.** Mint URL,
+inference provider and backend parameters, and other values currently
+supplied via CLI flags belong in the per-repo configuration under `.fullsend/`.
+The installer reads configuration instead of reconstructing it from flags.
+
+**2. Layered configuration with accessor-based lookup.** Configuration is
+stored in the target repository as:
+
+- `.fullsend/config.base.yaml` — the base layer (vendor preset or repo baseline).
+- `.fullsend/config.yaml` — the user overlay for repo-specific customization.
+
+**Relationship to the three-tier model.** [ADR 0003](0003-org-config-repo-convention.md)
+and `docs/architecture.md` describe configuration inheritance as upstream
+defaults, then org `.fullsend`, then per-repo overrides. Per-repo installation
+drops the dedicated org config repo; `config.base.yaml` takes the org tier's
+place. A vendor preset committed as `config.base.yaml` can be reused across
+repos in one org or distributed unchanged across org boundaries — the same
+portability benefit org-wide config provided, without a separate `<org>/.fullsend`
+repository. `config.yaml` remains the per-repo overlay. Lookup order is overlay
+→ base → **code defaults** in `internal/config` (and related packages): values
+not set in either file still resolve from compiled-in defaults, as today.
+Accessor methods implement that full chain; direct struct field access does not.
+
+All runtime and installer lookups go through methods on a configuration
+accessor (for example `MintURL()`, `InferenceProvider()`), not direct struct
+field access. Each accessor implements its own merge and fallback rules across
+layers (scalar override, deep merge, or required-in-overlay semantics as
+appropriate). The design must allow additional file layers beyond base + overlay
+in the future without changing call sites.
+
+**3. `--config` install flag for ready-made presets.** `fullsend github setup`
+accepts `--config <path-or-url>`. The installer:
+
+1. Fetches or reads the preset document.
+2. Commits it as `.fullsend/config.base.yaml` in the target repository.
+3. Writes a stub `.fullsend/config.yaml` containing only comments and empty or
+   minimal override fields for the adopter to customize.
+
+Presets may be local files or HTTPS URLs. The flag is optional; advanced
+installs that assemble configuration manually remain supported.
+
+**4. Drop per-adopter mint and inference enrollment from the install path.**
+When a preset targets shared infrastructure authorized via `job_workflow_ref`
+to workflows in `fullsend-ai/fullsend`, the installer does not run mint
+enrollment or inference WIF provisioning. Trust is established by the
+workflows the preset references, not by registering each repo with backend
+operators at install time.
+
+Follow-on ADRs will specify which upstream workflows are pinned, how inference
+backends validate `job_workflow_ref`, and compatibility for self-managed mint
+or inference paths that still require explicit enrollment.
+
+## Consequences
+
+- Common installs become a single command with a preset URL instead of a long
+  flag list plus separate mint and inference enrollment steps.
+- The `internal/config` package gains a layered accessor API; direct field reads
+  outside that package become a lint or review violation.
+- Preset upgrades can refresh `.fullsend/config.base.yaml` while preserving
+  repo edits in `.fullsend/config.yaml`, provided merge semantics are
+  documented per field.
+- Self-managed and air-gapped deployments keep working via hand-authored
+  configuration or flags that bypass shared presets.
+- Mint and inference operators shift from per-repo onboarding to backend policy
+  (workflow allowlists); security review moves to preset curation and
+  `job_workflow_ref` pinning rather than install-time enrollment calls.

Relevance

⭐⭐ Medium

No historical evidence found enforcing 100-line ADR body limit; past ADR feedback focuses on
accuracy/cross-refs (PR #1578).

PR-#1578

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

PR Compliance ID 1062092 limits ADR content to 100 lines (excluding frontmatter). This new ADR’s
body spans well over 100 lines (it runs from line 13 through line 121 in the added file).

docs/ADRs/0058-ready-made-configuration-presets.md[13-121]
Skill: writing-adrs

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
This ADR’s content (excluding YAML frontmatter) is longer than 100 lines, violating the ADR length constraint.

## Issue Context
The ADR currently includes extended explanatory text (e.g., relationship to the three-tier model, detailed installer steps, and follow-on specifics) that can likely be shortened and/or moved to `docs/architecture.md` or referenced ADRs/problem docs.

## Fix Focus Areas
- docs/ADRs/0058-ready-made-configuration-presets.md[13-121]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. ADR 0058 has four decisions ✗ Dismissed 📜 Skill insight ⚙ Maintainability

Description

docs/ADRs/0058-ready-made-configuration-presets.md records multiple distinct decisions (config
move, layering/accessors, --config preset installs, and dropping enrollments) in a single ADR.
This violates the requirement that each ADR capture exactly one decision, making future audits and
supersession unclear.

Code

docs/ADRs/0058-ready-made-configuration-presets.md[R54-107]

+## Decision
+
+**1. Move installation settings into configuration files.** Mint URL,
+inference provider and backend parameters, and other values currently
+supplied via CLI flags belong in the per-repo configuration under `.fullsend/`.
+The installer reads configuration instead of reconstructing it from flags.
+
+**2. Layered configuration with accessor-based lookup.** Configuration is
+stored in the target repository as:
+
+- `.fullsend/config.base.yaml` — the base layer (vendor preset or repo baseline).
+- `.fullsend/config.yaml` — the user overlay for repo-specific customization.
+
+**Relationship to the three-tier model.** [ADR 0003](0003-org-config-repo-convention.md)
+and `docs/architecture.md` describe configuration inheritance as upstream
+defaults, then org `.fullsend`, then per-repo overrides. Per-repo installation
+drops the dedicated org config repo; `config.base.yaml` takes the org tier's
+place. A vendor preset committed as `config.base.yaml` can be reused across
+repos in one org or distributed unchanged across org boundaries — the same
+portability benefit org-wide config provided, without a separate `<org>/.fullsend`
+repository. `config.yaml` remains the per-repo overlay. Lookup order is overlay
+→ base → **code defaults** in `internal/config` (and related packages): values
+not set in either file still resolve from compiled-in defaults, as today.
+Accessor methods implement that full chain; direct struct field access does not.
+
+All runtime and installer lookups go through methods on a configuration
+accessor (for example `MintURL()`, `InferenceProvider()`), not direct struct
+field access. Each accessor implements its own merge and fallback rules across
+layers (scalar override, deep merge, or required-in-overlay semantics as
+appropriate). The design must allow additional file layers beyond base + overlay
+in the future without changing call sites.
+
+**3. `--config` install flag for ready-made presets.** `fullsend github setup`
+accepts `--config <path-or-url>`. The installer:
+
+1. Fetches or reads the preset document.
+2. Commits it as `.fullsend/config.base.yaml` in the target repository.
+3. Writes a stub `.fullsend/config.yaml` containing only comments and empty or
+   minimal override fields for the adopter to customize.
+
+Presets may be local files or HTTPS URLs. The flag is optional; advanced
+installs that assemble configuration manually remain supported.
+
+**4. Drop per-adopter mint and inference enrollment from the install path.**
+When a preset targets shared infrastructure authorized via `job_workflow_ref`
+to workflows in `fullsend-ai/fullsend`, the installer does not run mint
+enrollment or inference WIF provisioning. Trust is established by the
+workflows the preset references, not by registering each repo with backend
+operators at install time.
+
+Follow-on ADRs will specify which upstream workflows are pinned, how inference
+backends validate `job_workflow_ref`, and compatibility for self-managed mint
+or inference paths that still require explicit enrollment.
+

Relevance

⭐⭐ Medium

No prior review history found requiring “exactly one decision per ADR”; similar ADR feedback is
about clarity/accuracy (PR #1814).

PR-#1814

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

PR Compliance ID 1062089 requires each ADR to record exactly one decision. The new ADR’s `##
Decision section enumerates four distinct decisions (**1** through **4**`).

docs/ADRs/0058-ready-made-configuration-presets.md[54-106]
Skill: writing-adrs

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`docs/ADRs/0058-ready-made-configuration-presets.md` contains multiple separate decisions in the `## Decision` section (numbered 1-4). The compliance rule requires exactly one decision per ADR.

## Issue Context
If these are genuinely separate decisions, they need separate ADRs (with explicit cross-references/supersession where appropriate). If they are all facets of one decision, rewrite the Decision section to state a single decision clearly, and move the remaining details to `## Consequences` or to follow-on ADRs.

## Fix Focus Areas
- docs/ADRs/0058-ready-made-configuration-presets.md[54-107]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. Config location contradiction ✓ Resolved 🐞 Bug ⚙ Maintainability

Description

docs/architecture.md adds the per-repo preset model (config written into the target repo) but still
states that platform configuration lives in the adopting org’s .fullsend repository, leaving two
conflicting sources of truth for configuration location.

Code

docs/architecture.md[49]

+- Ready-made configuration presets: `fullsend github setup --config <path-or-url>` installs a vendor preset as `.fullsend/config.base.yaml` and a stub `.fullsend/config.yaml` overlay in the target repository; mint URL, inference backend, and related settings live in configuration files resolved through accessor methods, not CLI flags. Shared-infrastructure presets drop per-adopter mint and inference enrollment in favor of `job_workflow_ref` trust to upstream workflows ([ADR 0058](ADRs/0058-ready-made-configuration-presets.md)).

Relevance

⭐⭐⭐ High

Team historically accepts fixing docs/architecture.md inconsistencies and inaccuracies (e.g.,
accepted corrections in PR #2334).

PR-#2334

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The architecture doc simultaneously asserts an org-level .fullsend repo as the configuration
source while also documenting per-repo preset installation that writes config into each target repo;
ADR 0058 supports the per-repo model by stating config.base.yaml replaces the org tier for
per-repo installs.

docs/architecture.md[36-37]
docs/architecture.md[49-49]
docs/architecture.md[66-66]
docs/ADRs/0058-ready-made-configuration-presets.md[67-75]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`docs/architecture.md` now contains conflicting statements about where configuration is defined:
- It still claims infra/sandbox configuration is specified in the adopting org’s `.fullsend` **repository**.
- It now also describes per-repo installs writing `.fullsend/config.base.yaml` and `.fullsend/config.yaml` into the **target repository**.

This ambiguity can mislead readers (and future implementers) about which model applies and where to look for configuration.

### Issue Context
ADR 0058 explicitly introduces per-repo layered configuration (`config.base.yaml` + `config.yaml`) and explains it replaces the org-tier config in per-repo installation.

### Fix Focus Areas
- docs/architecture.md[36-37]
- docs/architecture.md[49-49]
- docs/architecture.md[66-66]

Suggested change: update the earlier “org `.fullsend` repository” sentences to explicitly distinguish **per-org** installs (org-level `.fullsend` repo) from **per-repo** installs (per-repo `.fullsend/` directory with `config.base.yaml` + `config.yaml`), so the document has one coherent “current truth.”

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

4. Resolved question not struck through 📜 Skill insight ⚙ Maintainability

Description

docs/problems/governance.md marks the bootstrap question as decided in ADR 0058 but does not apply
the required strikethrough annotation. This violates the rule for how resolved problem-doc questions
must be recorded.

Code

docs/problems/governance.md[34]

+- How do we handle the bootstrap problem — who sets up the initial agent configuration for a new repo, and how is that initial setup secured? (Preset-based install and `config.base.yaml` / `config.yaml` layering decided in [ADR 0058](../ADRs/0058-ready-made-configuration-presets.md); workflow pinning and backend policy remain open.)

Relevance

⭐⭐⭐ High

Repo updates problem docs to mark questions as decided/linked to ADRs; similar “resolve open
questions” doc hygiene accepted (PR #1578).

PR-#1578

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

PR Compliance ID 1062102 requires that when an ADR resolves an open question in a problem doc, the
question must be kept and marked with strikethrough plus an ADR link. The updated bullet states the
item was decided in ADR 0058 but is not struck through.

docs/problems/governance.md[34-34]
Skill: writing-adrs

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The governance problem doc indicates the bootstrap question is decided in ADR 0058, but the question is not annotated using the required strikethrough format.

## Issue Context
If only part of the question is decided, split it into (a) a struck-through decided question with an ADR link and (b) a remaining open question capturing what is still unknown (e.g., workflow pinning/backend policy).

## Fix Focus Areas
- docs/problems/governance.md[34-34]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 5:22 AM UTC · Completed 5:34 AM UTC
Commit: 876c91c · View workflow run →

[fullsend-ai-review]

Review skipped — this PR is already merged.

The /fs-review command only reviews open pull requests.

_{Posted by fullsend post-review check}