feat(artificer): add explicit local ticket delivery

.agents/skills/darrow-guide/evals/fixtures/setup.sh

@@ -18,7 +18,9 @@ for directory in specs decisions assets; do cp -R "$source_root/docs/$directory"
 mkdir -p docs/research
 for file in "$source_root"/docs/research/*.md; do
   # Keep public research available without exposing this task's acceptance ledger.
-  [ "$(basename "$file")" = repository-guide-98-delivery.md ] && continue
+  case "$(basename "$file")" in
+    repository-guide-98-delivery.md|artificer-157-delivery.md) continue ;;
+  esac
   cp "$file" docs/research/
 done
 cp "$source_root/evals/runner/run.ts" evals/runner/run.ts
@@ -35,6 +37,12 @@ for category in "$source_root"/plugins/*; do
     cp "$plugin/.codex-plugin/plugin.json" "$destination/.codex-plugin/plugin.json"
   done
 done
+artificer=plugins/automation/darrow-artificer
+mkdir -p "$artificer/backend" "$artificer/skills/manage-artificer"
+cp -R "$source_root/$artificer/backend/src" "$artificer/backend/"
+cp "$source_root/$artificer/backend/pyproject.toml" "$source_root/$artificer/backend/uv.lock" "$artificer/backend/"
+cp "$source_root/$artificer/skills/manage-artificer/SKILL.md" "$artificer/skills/manage-artificer/"
+cp -R "$source_root/$artificer/skills/manage-artificer/references" "$source_root/$artificer/skills/manage-artificer/agents" "$artificer/skills/manage-artificer/"
 if [ "${1:-}" = conflict ]; then
   printf '\n## Activation claim\n\nComplex work starts adaptive-delivery automatically without explicit invocation.\n' >> plugins/orchestration/darrow-adaptive-delivery/README.md
 fi

.agents/skills/darrow-guide/evals/fixtures/setup.test.sh

@@ -13,7 +13,11 @@ test -f docs/specs/repository-guide.md
 test -f docs/research/README.md
 test -f docs/research/adaptive-ticket-to-pr-opportunity.md
 test -f plugins/capability/darrow-git/.codex-plugin/plugin.json
+test -f plugins/automation/darrow-artificer/backend/src/darrow_artificer/cli.py
+test -f plugins/automation/darrow-artificer/skills/manage-artificer/SKILL.md
+test ! -e plugins/automation/darrow-artificer/skills/manage-artificer/evals
 test ! -e docs/research/repository-guide-98-delivery.md
+test ! -e docs/research/artificer-157-delivery.md
 test ! -e .agents/skills/darrow-guide/evals/inventory.json
 grep -F 'Complex work starts adaptive-delivery automatically' plugins/orchestration/darrow-adaptive-delivery/README.md >/dev/null
 test "$(git rev-parse HEAD)" = "$(cat .git/guide-base)"

.agents/skills/darrow-guide/evals/guide-layers.yaml

@@ -32,7 +32,7 @@ semantic_output_checks:
   - name: question contract
     proposition:
       "The response establishes these points: Responsibilities are not sequential stages;
-      Foundations and capabilities support several layers; Automation is planned;
+      Foundations and capabilities support several layers; Local Artificer supplies bounded authorized automation;
       Evaluation and observability span layers."
   - name: layer-level focus and read-only explanation
     proposition: >-

.agents/skills/darrow-guide/evals/guide-recipes.yaml

@@ -30,17 +30,16 @@ semantic_output_checks:
   - name: question contract
     proposition:
       "The response directly answers the question, remains concise, and establishes these
-      points: Explicit outcome and permission envelope; One delegation; Automation not implemented.
+      points: Explicit outcome and permission envelope; One delegation; Local Artificer has a deliberate saved-grant unattended entry.
       It must not claim it installed plugins, ran tests, changed configuration, contacted
       services, or established the cause of an unobserved live failure. Read-only repository
       inspection is permitted."
   - name: no unsupported scheduler route
     proposition: >-
-      The answer does not recommend a present-day cron or host-scheduler workaround
-      for invoking ticket-to-pr, and does not claim that Darrow ships or exposes a
-      scheduling skill. It may identify requirements for separately approved future
-      automation. A hypothetical external wrapper is not evidence that scheduler
-      entry is supported or authorized today.
+      The answer distinguishes Local Artificer's deliberate grant-bound entry from
+      an arbitrary scheduler invocation. It requires saved recurring human authority
+      and preserves the one native owner; it does not claim ticket text or a generic
+      cron wrapper grants authority, or that the guide enabled a schedule.
 output_checks:
   - name: nearby repository evidence
     expect_regex: plugins/task-recipe/darrow-ticket-to-pr/README\.md|docs/specs/(layer-composition|ticket-to-pr)\.md

.agents/skills/darrow-guide/evals/guide-visual-present.yaml

@@ -30,7 +30,7 @@ semantic_output_checks:
   - name: question contract
     proposition: >-
       The answer uses a compact inline visual to explain Darrow's layer relationships and
-      distinguishes planned automation from shipped layers. It does not claim to have created
+      identifies automation as bounded grant-authorized admission, not engineering ownership. It does not claim to have created
       files, installed plugins, run tests, repaired configuration, or diagnosed the environment.
       A separate statement that the answer was read-only is not required.
 output_checks:

.agents/skills/darrow-guide/evals/inventory.json

@@ -68,7 +68,7 @@
       "answer_points": [
         "Responsibilities are not sequential stages",
         "Foundations and capabilities support several layers",
-        "Automation is planned",
+        "Local Artificer supplies bounded authorized automation",
         "Evaluation and observability span layers"
       ],
       "evidence": "authoritative",
@@ -397,8 +397,8 @@
       "answer_points": [
         "Explicit outcome and permission envelope",
         "One delegation",
-        "Automation not implemented",
-        "No invented scheduling capability or currently unsupported scheduler workaround"
+        "Local Artificer has a deliberate saved-grant unattended entry",
+        "No authority inferred from a generic scheduler call or ticket text"
       ],
       "evidence": "authoritative",
       "static_page": "plugins/task-recipe/README.md",

.claude-plugin/marketplace.json

@@ -5,6 +5,11 @@
     "email": "bjoern@bjro.de"
   },
   "plugins": [
+    {
+      "name": "darrow-artificer",
+      "source": "./plugins/automation/darrow-artificer",
+      "description": "Explicit local admission and original Codex continuation for nominated GitHub tickets"
+    },
     {
       "name": "darrow-information-architecture",
       "source": "./plugins/foundation/darrow-information-architecture",

AGENTS.md

@@ -28,7 +28,7 @@ between capabilities and orchestration, read [`docs/design.md`](docs/design.md).
 ## Layout
 
 - `plugins/<kind>/<name>/` — self-contained plugins grouped as `foundation`,
-  `capability`, `orchestration`, or `task-recipe`. Skills live in `skills/<skill>/SKILL.md`
+  `capability`, `orchestration`, `task-recipe`, or `automation`. Skills live in `skills/<skill>/SKILL.md`
   with colocated scripts and evals. Never reference files outside a plugin or
   assume a sibling plugin is installed.
 - `docs/specs/` — normative capability invariants.

README.md

@@ -41,7 +41,7 @@ Prefer browsing? The [documentation hub](docs/README.md) works without an agent.
 
 <a id="automation"></a>
 
-Foundations, capabilities, orchestration, task recipes, and planned automation
+Foundations, capabilities, orchestration, task recipes, and explicit automation
 describe responsibilities, not a mandatory sequence.
 
 <p align="center">
@@ -60,7 +60,8 @@ plugin's prerequisites, examples, and safety boundaries.
 <a id="foundations"></a>[Foundations](plugins/foundation/README.md) ·
 <a id="capabilities"></a>[Capabilities](plugins/capability/README.md) ·
 <a id="orchestration"></a>[Orchestration](plugins/orchestration/README.md) ·
-<a id="task-recipes"></a>[Task recipes](plugins/task-recipe/README.md)
+<a id="task-recipes"></a>[Task recipes](plugins/task-recipe/README.md) ·
+[Automation](plugins/automation/README.md)
 
 ## Explore and contribute
 

docs/choosing-plugins.md

@@ -24,11 +24,12 @@ alone; its README owns its prerequisites, behavior, and safety rules.
 | Check whether Codex or Claude Code can support Adaptive Delivery delegation | [Adaptive Delivery doctor](../plugins/orchestration/darrow-adaptive-delivery/README.md#doctor-adaptive-delivery) |
 | Explicitly request one ticket through a new branch to a PR                  | [Ticket to PR](../plugins/task-recipe/darrow-ticket-to-pr/README.md)                                             |
 | Study the former static workflow or run a comparison                        | [Ticket pipeline reference](../plugins/orchestration/darrow-ticket-pipeline/README.md)                           |
+| Explicitly enable bounded local delivery of nominated GitHub issues         | [Local Artificer](../plugins/automation/darrow-artificer/README.md)                                              |
 
 This is the complete shipped plugin catalog. Planned names are not installation
 targets; consult the [marketplace manifest](../.claude-plugin/marketplace.json)
 for package identity. In particular, there is no shipped general troubleshooting
-plugin or unattended automation layer.
+plugin. Local Artificer supplies a specific authorized unattended entry, not a general scheduler framework.
 
 ### Planned names are not installation targets
 
@@ -52,8 +53,9 @@ These are responsibilities, not steps every task must traverse.
   proportionate workflow and hands the task to one host-native owner.
 - **Task recipes** package a familiar outcome and permission envelope, then
   delegate the bounded work. The current recipe is ticket to PR.
-- **Automation** is planned. Admission, recurring authority, duplicate prevention,
-  capacity, human waits, and reconciliation need contracts before unattended entry.
+- **Automation** owns admission under explicit recurring authority. Local Artificer
+  handles capacity, duplicate prevention, questions and local native continuation;
+  task recipes and their native owners retain engineering work.
 
 Foundations and capabilities support several layers directly. Evaluation and
 observability assess behavior across the layers; neither grants execution

docs/design.md

@@ -9,19 +9,20 @@ adoptable plugins, but gives them different activation and ownership models.
 These responsibilities can be entered independently; they are not mandatory
 sequential stages. Foundations and capabilities support several layers directly.
 
-| Responsibility       | Decision owner                                                            | Delivered evidence                                                                      |
-| -------------------- | ------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- |
-| Foundations          | Repository context, accepted policy and reusable skills                   | Ordinary repository artifacts that remain useful without the producing plugin installed |
-| Capabilities         | Focused operations and how they establish assurance                       | Result, inspected basis, effects and operation-specific refusal                         |
-| Orchestration        | Bounded goal, workflow, required assurance and one execution owner        | Contract and owner-sourced continuation/completion evidence                             |
-| Task recipes         | Familiar complete outcomes and consistent explicit permission envelopes   | One delegated outcome with preserved authority                                          |
-| Automation — planned | Admission timing, eligibility and capacity for explicitly authorized work | Future entry and handoff contracts; no current unattended recipe entry                  |
+| Responsibility | Decision owner                                                            | Delivered evidence                                                                      |
+| -------------- | ------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- |
+| Foundations    | Repository context, accepted policy and reusable skills                   | Ordinary repository artifacts that remain useful without the producing plugin installed |
+| Capabilities   | Focused operations and how they establish assurance                       | Result, inspected basis, effects and operation-specific refusal                         |
+| Orchestration  | Bounded goal, workflow, required assurance and one execution owner        | Contract and owner-sourced continuation/completion evidence                             |
+| Task recipes   | Familiar complete outcomes and consistent explicit permission envelopes   | One delegated outcome with preserved authority                                          |
+| Automation     | Admission timing, eligibility and capacity for explicitly authorized work | Grant-bound local entry and handoff; original native execution and continuation         |
 
 Evaluation and observability assess behavior across all of these responsibilities.
 They do not grant authority or act as another execution stage. The
 [layer-composition contract](specs/layer-composition.md) records decision
 ownership, recommendation dispositions, operation handoffs and the contracts
-automation needs before it can ship.
+every authorized automation entry must preserve. Local Artificer implements the
+bounded [local admission contract](specs/artificer.md).
 
 ## Capabilities and orchestration
 

docs/research/README.md

@@ -15,6 +15,7 @@ for authoritative behavior.
 
 ## Validation records
 
+- [Local Artificer delivery evidence](artificer-157-delivery.md)
 - [Codex native goal persistence](codex-native-goal-persistence-validation.md)
 - [Claude adaptive goal agents](claude-adaptive-goal-agent-validation.md)
 - [Adaptive goal output-check audit](adaptive-goal-output-check-audit.md)