foundry-implementation-actor 0.5.0__tar.gz → 0.6.0__tar.gz

foundry_implementation_actor-0.6.0/.github/workflows/release.yml

@@ -0,0 +1,210 @@
+name: release
+on:
+  push:
+    tags: ["v*"]
+
+  # A REGISTRY ADDED AFTER A TAG WAS ALREADY CUT. The image job below publishes to two registries,
+  # and the second one was not always there. Running this workflow by hand backfills the image for
+  # a version whose wheel is already on PyPI — without inventing a version number whose only
+  # content is "the last release missed a registry".
+  #
+  # THE TAG IS AN INPUT, NOT THE REF THIS RUNS FROM. GitHub takes the workflow FILE from the ref it
+  # is dispatched on, and the tag needing a backfill is by definition older than the workflow that
+  # can do it — dispatching on that tag would run the very file that lacks this trigger. So run it
+  # from the default branch and name the tag here; the checkout below takes the CONTENT from the
+  # tag, and the version gate still refuses a tag that disagrees with the `pyproject.toml` beside
+  # it.
+  workflow_dispatch:
+    inputs:
+      tag:
+        description: "Existing tag to publish an image for, e.g. v0.5.0"
+        required: true
+
+# PyPI Trusted Publishing (OIDC) — no token is stored anywhere. The one-time setup is a pending
+# publisher on pypi.org naming this repo and this workflow; after the first release it becomes a
+# normal publisher. See README.
+permissions:
+  id-token: write   # PyPI Trusted Publishing
+  contents: read
+  packages: write   # the image, to this repo's own container registry
+
+jobs:
+  publish:
+    # ONLY ON A TAG PUSH. A manual run exists to backfill an IMAGE (see `on:` above), and PyPI
+    # refuses a version it already holds — so re-uploading is not merely redundant, it fails, and
+    # would take the image job down with it.
+    if: github.event_name == 'push'
+    runs-on: ubuntu-latest
+    environment: pypi
+    steps:
+      - uses: actions/checkout@v4
+      - uses: astral-sh/setup-uv@v5
+
+      - name: build
+        # No fetch step and no external token: the contract is committed here. A release depends
+        # on nothing but this checkout and PyPI.
+        run: uv build
+
+      - name: the wheel must carry its contract
+        run: |
+          uv venv /tmp/probe
+          uv pip install --python /tmp/probe/bin/python -q dist/*.whl
+          /tmp/probe/bin/foundry-implementation-actor lint examples/ACME.PARTS.CAP.SUP.007.WID-implementation
+
+      - name: the wheel must carry the actor's own cards
+        # Same reason as the line above, for the other half of what this package ships. The
+        # `-actor` suffix asserts a papeete-actor underneath (ADR-ECO-0022); a wheel published
+        # without its cards makes the name a claim the artifact cannot honour, and a published
+        # version is not something to discover that from.
+        run: |
+          /tmp/probe/bin/papeete-actor-synchronous-messaging lint-card \
+            "$(/tmp/probe/bin/python -c 'from foundry_implementation_actor import cards_path; print(cards_path())')"
+
+      - name: grounding renders a CLAUDE.md whose imports resolve
+        # BEFORE the upload, not after. A wheel that ships without its schema, or whose grounding
+        # emits an @-import to a file it never wrote, produces sessions grounded in nothing that
+        # look identical to correct ones. That is not something to discover from a published
+        # version.
+        run: /tmp/probe/bin/python scripts/probe_grounding.py examples/ACME.PARTS.CAP.SUP.007.WID-implementation
+
+      - name: publish to PyPI
+        run: uv publish --trusted-publishing always
+
+  # ── the image, from the same tag and the same checkout ────────────────────────────────────────
+  #
+  # TWO ARTIFACTS, ONE RELEASE (ADR-FIA-0005). A use pins an image; an embedder pins a wheel; both
+  # are this package at this version. A tag that produced one and not the other leaves a consumer
+  # unable to take the release at all — so this job builds the wheel again from the same checkout
+  # rather than installing the one just uploaded: the image must not depend on PyPI having already
+  # indexed it, and must not be able to pick up a different build of the same version.
+  #
+  # It runs AFTER the wheel is published, not beside it. A failed upload should not leave an image
+  # published for a version that does not exist on PyPI; the reverse — a wheel with the image still
+  # to come — is recoverable by re-running this job alone.
+  image:
+    needs: publish
+    # `needs` still orders this after the wheel on a tag push. On a manual backfill `publish` is
+    # skipped, and a skipped dependency skips its dependents too unless `always()` says otherwise —
+    # so the condition has to name both cases rather than relying on `needs` alone.
+    if: always() && (needs.publish.result == 'success' || github.event_name == 'workflow_dispatch')
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+        with:
+          # Empty on a tag push, which is `checkout`'s own default — the ref that triggered the
+          # run. On a manual backfill it is the tag being republished, so every step below reads
+          # that tag's own tree rather than whatever the default branch has moved on to.
+          ref: ${{ inputs.tag }}
+
+      - uses: astral-sh/setup-uv@v5
+
+      - name: the version is the tag
+        # The tag is what a consumer writes in a FROM line. A tag that disagrees with
+        # pyproject.toml would publish an image whose own `version()` contradicts its name, which
+        # is exactly the confusion the CI gate above exists to prevent for the wheel. On a backfill
+        # this compares the named tag against the `pyproject.toml` checked out FROM that tag, so a
+        # typo in the input is refused rather than published under the wrong name.
+        id: version
+        env:
+          TAG: ${{ inputs.tag || github.ref_name }}
+        run: |
+          tag="${TAG#v}"
+          declared="$(uv run --quiet python -c             'import tomllib,pathlib; print(tomllib.loads(pathlib.Path("pyproject.toml").read_text())["project"]["version"])')"
+          [ "$tag" = "$declared" ] || { echo "::error::tag $TAG does not match pyproject version $declared"; exit 1; }
+          echo "version=$tag" >> "$GITHUB_OUTPUT"
+
+      - name: build
+        run: uv build
+
+      - uses: docker/login-action@v3
+        with:
+          registry: ghcr.io
+          username: ${{ github.actor }}
+          password: ${{ secrets.GITHUB_TOKEN }}
+
+      - name: the image, tagged and latest
+        env:
+          VERSION: ${{ steps.version.outputs.version }}
+          # `latest` FOLLOWS THE RELEASE STREAM, NOT A BACKFILL. A manual run exists to give an
+          # already-released version an image in a registry it missed; run against an older tag it
+          # would otherwise drag `latest` backwards onto it, silently, in whichever registry a
+          # consumer happens to pull from. The version tag is the whole point of a backfill —
+          # `latest` already names something newer, and stays there.
+          MOVE_LATEST: ${{ github.event_name == 'push' }}
+        run: |
+          image="ghcr.io/${{ github.repository }}"
+          docker build -f docker/Dockerfile -t "$image:$VERSION" -t "$image:latest" .
+          docker push "$image:$VERSION"
+          if [ "$MOVE_LATEST" = "true" ]; then docker push "$image:latest"; fi
+
+      # ── the product's own registry ────────────────────────────────────────────────────────────
+      #
+      # TWO REGISTRIES, ONE IMAGE. GHCR is where this package publishes; a product that RUNS uses
+      # of it pulls from its own registry, which its cluster already authenticates to and which a
+      # `FROM` line inside that cluster's builder can reach without a second credential. The base
+      # image has to exist in both, because the two are reached by different things: an embedder
+      # writing a Dockerfile reads the README and pins GHCR, while a use built by an in-cluster
+      # builder resolves its `FROM` against the registry that builder has a push token for.
+      #
+      # THE SAME IMAGE, NOT ANOTHER BUILD. `docker tag` re-points the build the step above already
+      # pushed, so both registries hold one digest. Building a second time would let them diverge —
+      # a base-image refresh between two steps of one job is enough — and nothing downstream would
+      # ever notice that `:0.5.0` meant two different things depending on where you pulled it.
+      #
+      # ONE VARIABLE NAMES THE WHOLE TARGET. `vars.PRODUCT_IMAGE` is the full repository path, e.g.
+      # `<name>.azurecr.io/<product>/foundry-implementation-actor`; the login server is its first
+      # segment. This package is generic across capabilities and names no product of its own — the
+      # same rule `tests/test_portability.py` enforces over `src/` — so the product that hosts a
+      # registry names itself in a repository variable rather than in this file.
+      #
+      # UNSET IS A VALID STATE, AND IT SAYS SO. A fork, or this repo before its credentials were
+      # added, publishes to GHCR alone; that is a `::notice`, not a failure. Configured-but-broken
+      # IS a failure — the push below is not best-effort, because an image the product's cluster
+      # cannot pull is the whole reason this block exists.
+      - name: is a product registry configured?
+        id: product
+        env:
+          PRODUCT_IMAGE: ${{ vars.PRODUCT_IMAGE }}
+        run: |
+          if [ -z "$PRODUCT_IMAGE" ]; then
+            echo "::notice::PRODUCT_IMAGE is unset — publishing to GHCR only"
+            echo "configured=false" >> "$GITHUB_OUTPUT"
+            exit 0
+          fi
+          case "$PRODUCT_IMAGE" in
+            */*/*) : ;;
+            *) echo "::error::PRODUCT_IMAGE must be <registry>/<path>/<repository>, got $PRODUCT_IMAGE"; exit 1 ;;
+          esac
+          echo "server=${PRODUCT_IMAGE%%/*}" >> "$GITHUB_OUTPUT"
+          echo "configured=true" >> "$GITHUB_OUTPUT"
+
+      - uses: docker/login-action@v3
+        if: steps.product.outputs.configured == 'true'
+        with:
+          registry: ${{ steps.product.outputs.server }}
+          username: ${{ secrets.ACR_PUSH_USERNAME }}
+          password: ${{ secrets.ACR_PUSH_PASSWORD }}
+
+      - name: the same image, in the product's registry
+        if: steps.product.outputs.configured == 'true'
+        env:
+          PRODUCT_IMAGE: ${{ vars.PRODUCT_IMAGE }}
+          VERSION: ${{ steps.version.outputs.version }}
+          MOVE_LATEST: ${{ github.event_name == 'push' }}
+        run: |
+          ghcr="ghcr.io/${{ github.repository }}"
+          docker tag "$ghcr:$VERSION" "$PRODUCT_IMAGE:$VERSION"
+          docker push "$PRODUCT_IMAGE:$VERSION"
+          if [ "$MOVE_LATEST" = "true" ]; then
+            docker tag "$ghcr:latest" "$PRODUCT_IMAGE:latest"
+            docker push "$PRODUCT_IMAGE:latest"
+          fi
+
+      - name: a use built on it is still an actor
+        # BEFORE the image is something anyone can pin — the same reason the grounding probe runs
+        # before the upload above. An image that builds but produces a use that does not conform is
+        # not something to discover from a published tag.
+        run: |
+          docker build --build-arg ACTOR_IMAGE=ghcr.io/${{ github.repository }}:${{ steps.version.outputs.version }} \
+            -t use:release examples/ACME.PARTS.CAP.SUP.007.WID-implementation
+          docker run --rm use:release foundry-implementation-actor lint /actor

{foundry_implementation_actor-0.5.0 → foundry_implementation_actor-0.6.0}/CLAUDE.md

@@ -29,7 +29,7 @@ There is no separate lint/format command configured in this repo.
 
 ## Architecture
 
-Seven modules under `src/foundry_implementation_actor/`:
+Eight modules under `src/foundry_implementation_actor/`:
 
 - **`config.py`** — `CapabilityConfig`. The heart. Loads the sidecar and derives **every**
   rendering of the capability id from two declared fields (`capability`, `source_repo`). Also
@@ -48,6 +48,10 @@ Seven modules under `src/foundry_implementation_actor/`:
   the derived wire contract only (door ids, each door's request/completion schema and engine).
   Prose and `actor.yaml`'s `name:` are deliberately not compared — a use should name its own
   capability. `lint` runs it beside the sidecar gate.
+- **`settings.py`** — `Settings`. How much a session may spend: turns and seconds, per door, as
+  one `field → environment variable` table with a `from_env` that refuses a value it cannot read.
+  `serve` fills the engine from it (ADR-FIA-0007). The defaults live here, not in `engine.py`,
+  because `engine.py` names the variable when a budget runs out.
 - **`cli.py`** — argparse wiring only, no logic of its own.
 
 Beside them, two folders of committed contract, both shipped in the wheel:
@@ -88,6 +92,15 @@ Beside them, two folders of committed contract, both shipped in the wheel:
 - **The clone is full, never `--depth 1`.** `papeete_version.compute()` runs `git describe --tags`
   against it and needs the matching tag's commit reachable.
 - **The generated `CLAUDE.md` appends** to one the repo already commits. Never overwrite.
+- **The image is one build in two registries.** GHCR is where this package publishes; a product's
+  own registry is where the in-cluster builder that resolves a use's `FROM` line can actually
+  authenticate (ADR-FIA-0006). `release.yml` `docker tag`s one build into both so they hold one
+  digest — never add a second `docker build`, and never hardcode a registry: the product names
+  itself in `vars.PRODUCT_IMAGE`, the same reason `src/` names no capability.
+- **A budget is an environment setting, and a door that runs out says what to change.** Turns and
+  timeouts are `Settings` fields with an `ENV` entry each, not constructor defaults `serve` never
+  passes (ADR-FIA-0007). Never add a knob without an entry in `ENV` and `ENGINE_KWARGS` — and never
+  put one in the sidecar: a capability declares what it is, not how long its actor may think.
 - **Never set `ANTHROPIC_API_KEY` in a container running this.** In `claude -p` non-interactive
   mode an API key in the environment is always preferred over `CLAUDE_CODE_OAUTH_TOKEN`, silently
   routing every session through metered billing. There is no warning; the only symptom is the bill.
@@ -104,7 +117,12 @@ similar weight rather than only writing it into code comments.
 ## Releasing
 
 Tag-triggered (`v*`) via `.github/workflows/release.yml`, publishing to PyPI through Trusted
-Publishing (OIDC) — no stored token. The release job builds the wheel, installs it into a throwaway
-venv, and renders a `CLAUDE.md` from a fixture sidecar, asserting its `@`-imports resolve, before
-publishing. `ci.yml` runs the suite plus two gates — *the wheel must carry its contract* and *the
-gate must run* — and reaches nothing outside its own checkout.
+Publishing (OIDC) — no stored token. The image goes to GHCR and, when `vars.PRODUCT_IMAGE` names
+one, to a product's own registry as well (ADR-FIA-0006). The workflow also accepts a manual run
+that takes a tag as an INPUT — dispatched from the default branch, because the file comes from the
+dispatched ref and a tag needing a backfill predates the workflow that can do it — to give an
+already-released version an image in a registry it missed; that run skips PyPI and does not move
+`latest`. The release job builds the wheel, installs it into
+a throwaway venv, and renders a `CLAUDE.md` from a fixture sidecar, asserting its `@`-imports
+resolve, before publishing. `ci.yml` runs the suite plus two gates — *the wheel must carry its
+contract* and *the gate must run* — and reaches nothing outside its own checkout.

{foundry_implementation_actor-0.5.0 → foundry_implementation_actor-0.6.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: foundry-implementation-actor
-Version: 0.5.0
+Version: 0.6.0
 Summary: Runs a headless Claude Code implementation session against one capability's own repo — a papeete-actor for one use, with the capability supplied by a sidecar.
 Project-URL: Homepage, https://github.com/papeete-hub/foundry-implementation-actor
 Author-email: Papeete Consulting <yoann.remy@outlook.com>
@@ -70,7 +70,7 @@ ground_in:
 and, beside it, a four-line Dockerfile:
 
 ```dockerfile
-FROM ghcr.io/papeete-hub/foundry-implementation-actor:0.5.0
+FROM ghcr.io/papeete-hub/foundry-implementation-actor:0.5.1
 RUN pip install --no-cache-dir kpack==2.0.1 kontract==0.1.0   # what this sidecar's ground_in names
 COPY actor-agentic-context.yaml /actor/
 RUN foundry-implementation-actor render-cards /actor && foundry-implementation-actor lint /actor
@@ -193,7 +193,9 @@ task does not determine this"* is a legitimate answer, and it is the most useful
 
 `assess-task` is a **query**, not an action — *"a promise to answer, from this actor's own state
 and nothing invented."* It clones read-only, grounds itself exactly as the implement door does, and
-is invoked with `Read,Glob,Grep` and no `Write`, `Edit` or `Bash`. A door that **cannot** write
+is invoked with `--tools Read,Glob,Grep`, so `Write`, `Edit` and `Bash` are absent from the session
+rather than merely unapproved (0.5.0 passed only `--allowedTools`, which removes nothing — see
+ADR-FIA-0004's amendment). A door that **cannot** write
 beats a door asked not to. It registers no handler either: with an engine and no handler,
 `Actor.receive()` returns the judged dict as the reply, and there is nothing to contain because
 nothing is produced.
@@ -285,6 +287,31 @@ Publishing additionally needs `IMAGE_REGISTRY` and `BUILDKIT_HOST`. There is no
 no docker socket anywhere in this design — `buildctl` is a client, which is why an actor running
 this can be an ordinary Pod.
 
+## What a session may spend
+
+Environment, read once at boot by `serve`; constructor keywords on `Settings` for an embedder. The
+budget is **not** a sidecar field: a capability declares what it is, not how long its actor may
+think (ADR-FIA-0007).
+
+| variable | default | what it costs to raise |
+|---|---|---|
+| `MAX_TURNS` | `60` | `implement-task`'s turns. A turn is a model call plus a tool call; raising it buys a slower-to-navigate repo more room, and buys a session that has lost the plot more room to keep losing it |
+| `SESSION_TIMEOUT_S` | `1800` | `implement-task`'s wall clock. The caller's own door timeout has to exceed it, or a slow success arrives as "did not answer" |
+| `ASSESS_MAX_TURNS` | `15` | `assess-task`'s turns. It reads and answers; it cannot write |
+| `ASSESS_TIMEOUT_S` | `600` | `assess-task`'s wall clock. Round 0 blocks on it, before anything is built |
+| `CLONE_TIMEOUT_S` | `120` | the full clone, per door call |
+| `FETCH_TIMEOUT_S` | `120` | each `ground_in` fetch, per door call |
+
+**The defaults have not moved** since these became reachable; they are what every use was already
+running. A value that is not a positive integer is refused at boot, naming itself, rather than
+silently falling back — so a raised budget that was misspelt crash-loops with the reason on stdout
+instead of changing nothing. The four session knobs are on the `actor-started` record too, so a run
+that ran out of budget can be read against the budget it actually had.
+
+A door that runs out says so in those terms: `implement-task ran out of turns (max_turns=60) and
+was stopped mid-work, so nothing it produced is kept — raise MAX_TURNS on this actor's Deployment,
+or narrow the task.`
+
 ## CLI
 
 ```bash
@@ -329,6 +356,32 @@ move, not a rewrite."*
 
 `adr/` records the decisions. Design rationale belongs there, not in commit messages.
 
+## Releasing, and which registry to pin
+
+A tag (`v*`) publishes two artifacts at one version — the wheel to PyPI, and the image to **two
+registries** holding the same digest (ADR-FIA-0006):
+
+| Registry | Pin it when |
+|---|---|
+| `ghcr.io/papeete-hub/foundry-implementation-actor` | you are writing a use's Dockerfile yourself, and build it with your own Docker |
+| a product's own registry, `vars.PRODUCT_IMAGE` | the use is built **in-cluster**, by a builder whose one registry credential is that product's |
+
+The second exists because `buildctl` resolves a `FROM` line client-side against the single registry
+credential it was handed — so a use built by the cluster's shared builder can only reach the
+product's own registry, whatever the README says. The push is skipped, with a notice, when
+`vars.PRODUCT_IMAGE` is unset.
+
+To give an already-released version an image in a registry it missed, run the workflow by hand from
+the default branch with the tag as its input — it checks that tag out, and refuses it if it
+disagrees with the `pyproject.toml` beside it:
+
+```bash
+gh workflow run release.yml --ref main -f tag=v0.5.0
+```
+
+That run skips PyPI (which refuses a version it already holds) and does not move `latest` in either
+registry.
+
 ## Development
 
 ```bash

{foundry_implementation_actor-0.5.0 → foundry_implementation_actor-0.6.0}/README.md

@@ -47,7 +47,7 @@ ground_in:
 and, beside it, a four-line Dockerfile:
 
 ```dockerfile
-FROM ghcr.io/papeete-hub/foundry-implementation-actor:0.5.0
+FROM ghcr.io/papeete-hub/foundry-implementation-actor:0.5.1
 RUN pip install --no-cache-dir kpack==2.0.1 kontract==0.1.0   # what this sidecar's ground_in names
 COPY actor-agentic-context.yaml /actor/
 RUN foundry-implementation-actor render-cards /actor && foundry-implementation-actor lint /actor
@@ -170,7 +170,9 @@ task does not determine this"* is a legitimate answer, and it is the most useful
 
 `assess-task` is a **query**, not an action — *"a promise to answer, from this actor's own state
 and nothing invented."* It clones read-only, grounds itself exactly as the implement door does, and
-is invoked with `Read,Glob,Grep` and no `Write`, `Edit` or `Bash`. A door that **cannot** write
+is invoked with `--tools Read,Glob,Grep`, so `Write`, `Edit` and `Bash` are absent from the session
+rather than merely unapproved (0.5.0 passed only `--allowedTools`, which removes nothing — see
+ADR-FIA-0004's amendment). A door that **cannot** write
 beats a door asked not to. It registers no handler either: with an engine and no handler,
 `Actor.receive()` returns the judged dict as the reply, and there is nothing to contain because
 nothing is produced.
@@ -262,6 +264,31 @@ Publishing additionally needs `IMAGE_REGISTRY` and `BUILDKIT_HOST`. There is no
 no docker socket anywhere in this design — `buildctl` is a client, which is why an actor running
 this can be an ordinary Pod.
 
+## What a session may spend
+
+Environment, read once at boot by `serve`; constructor keywords on `Settings` for an embedder. The
+budget is **not** a sidecar field: a capability declares what it is, not how long its actor may
+think (ADR-FIA-0007).
+
+| variable | default | what it costs to raise |
+|---|---|---|
+| `MAX_TURNS` | `60` | `implement-task`'s turns. A turn is a model call plus a tool call; raising it buys a slower-to-navigate repo more room, and buys a session that has lost the plot more room to keep losing it |
+| `SESSION_TIMEOUT_S` | `1800` | `implement-task`'s wall clock. The caller's own door timeout has to exceed it, or a slow success arrives as "did not answer" |
+| `ASSESS_MAX_TURNS` | `15` | `assess-task`'s turns. It reads and answers; it cannot write |
+| `ASSESS_TIMEOUT_S` | `600` | `assess-task`'s wall clock. Round 0 blocks on it, before anything is built |
+| `CLONE_TIMEOUT_S` | `120` | the full clone, per door call |
+| `FETCH_TIMEOUT_S` | `120` | each `ground_in` fetch, per door call |
+
+**The defaults have not moved** since these became reachable; they are what every use was already
+running. A value that is not a positive integer is refused at boot, naming itself, rather than
+silently falling back — so a raised budget that was misspelt crash-loops with the reason on stdout
+instead of changing nothing. The four session knobs are on the `actor-started` record too, so a run
+that ran out of budget can be read against the budget it actually had.
+
+A door that runs out says so in those terms: `implement-task ran out of turns (max_turns=60) and
+was stopped mid-work, so nothing it produced is kept — raise MAX_TURNS on this actor's Deployment,
+or narrow the task.`
+
 ## CLI
 
 ```bash
@@ -306,6 +333,32 @@ move, not a rewrite."*
 
 `adr/` records the decisions. Design rationale belongs there, not in commit messages.
 
+## Releasing, and which registry to pin
+
+A tag (`v*`) publishes two artifacts at one version — the wheel to PyPI, and the image to **two
+registries** holding the same digest (ADR-FIA-0006):
+
+| Registry | Pin it when |
+|---|---|
+| `ghcr.io/papeete-hub/foundry-implementation-actor` | you are writing a use's Dockerfile yourself, and build it with your own Docker |
+| a product's own registry, `vars.PRODUCT_IMAGE` | the use is built **in-cluster**, by a builder whose one registry credential is that product's |
+
+The second exists because `buildctl` resolves a `FROM` line client-side against the single registry
+credential it was handed — so a use built by the cluster's shared builder can only reach the
+product's own registry, whatever the README says. The push is skipped, with a notice, when
+`vars.PRODUCT_IMAGE` is unset.
+
+To give an already-released version an image in a registry it missed, run the workflow by hand from
+the default branch with the tag as its input — it checks that tag out, and refuses it if it
+disagrees with the `pyproject.toml` beside it:
+
+```bash
+gh workflow run release.yml --ref main -f tag=v0.5.0
+```
+
+That run skips PyPI (which refuses a version it already holds) and does not move `latest` in either
+registry.
+
 ## Development
 
 ```bash

{foundry_implementation_actor-0.5.0 → foundry_implementation_actor-0.6.0}/adr/ADR-FIA-0004-the-three-amigos-round.md

@@ -69,6 +69,13 @@ with `Read,Glob,Grep` and no `Write`, `Edit` or `Bash`. **A door that cannot wri
 asked not to** — the same discipline as `handler.py`'s containment check standing behind the
 implement door's write boundary.
 
+*Amended in 0.5.1, after the first live run.* Up to 0.5.0 that list was passed only as
+`--allowedTools`, which PRE-APPROVES the tools it names and removes nothing: a live assess session
+ran Bash three times. The door was asked not to write after all. It is now also passed as
+`--tools`, which is what takes every other built-in out of the session, and a test pins both flags.
+The same run showed commitments coming back as prose strings ("E1: …", "E4/E5: …") that nothing
+could attach to an expectation, so the prompt now requires one `{id, commitment}` object per entry.
+
 **4. `acceptance_surface` is an OPTIONAL payload field on `implement-task`.** The door works
 exactly as before without it. The DoD is what the caller asked for; the surface is what dev and
 test agreed it means, and where the surface is more specific, it wins.
@@ -124,9 +131,11 @@ tuning, and it is a constructor keyword.
 - **Expectation ids are worth more than this round.** Because each carries a stable `id`, a failing
   verdict can name agreed expectations instead of scraped pytest lines, and `remediation_context`
   can stop being free prose. Neither is done here.
-- **The other two halves are specified, not built.** The testing actor's `propose-acceptance` and
-  the orchestrating actor's round 0 live in instance repos that are not yet `foundry-*` packages.
-  The round belongs after that actor unpacks its payload and before its attempt loop begins.
+- **The other two halves are specified here and built elsewhere.** The testing actor's
+  `propose-acceptance` is `foundry-testing-actor` (ADR-FTA-0002), and the orchestrating actor's
+  round 0 is `foundry-task-orchestration-actor` (ADR-FTOA-0002), both extracted from their
+  instance repos the way ADR-FIA-0005 extracted this one. The round runs after that actor unpacks
+  its payload and before its attempt loop begins.
 - **Not decided here:** whether the agreed surface should also be committed somewhere durable
   rather than only passed between doors, and whether `definition_of_done` should eventually be
   absorbed into it rather than sitting beside it.

foundry_implementation_actor-0.6.0/adr/ADR-FIA-0006-the-image-is-published-to-two-registries.md

@@ -0,0 +1,104 @@
+---
+id: ADR-FIA-0006
+title: "The image is published to two registries, and names neither in its source"
+status: Proposed
+date: 2026-09-11
+supersedes: []
+references:
+  - ../.github/workflows/release.yml
+  - ADR-FIA-0005-the-actor-ships-an-image.md
+---
+
+# ADR-FIA-0006 — The image is published to two registries, and names neither in its source
+
+## Context
+
+ADR-FIA-0005 made the base image half of what a release is: a use is one sidecar and a `FROM`
+line, so the image is not a convenience beside the wheel, it is the thing a use is built out of.
+The first release to carry one (0.5.0) published it to GHCR, because that is the registry a
+GitHub-hosted package gets for free and the only one the workflow had a credential for.
+
+That is the wrong registry for the consumer that actually exists. A use is built **inside a
+cluster**, by the shared rootless builder `papeete-platform`'s `modules/buildkit` installs, which
+resolves a `FROM` line client-side against the registry it holds a push token for — an Azure
+Container Registry, provisioned by that repo's `modules/acr` with scope maps over the product's own
+repository prefixes. `buildctl` has exactly one registry credential, mounted as its
+`$DOCKER_CONFIG/config.json`, and it is not a GHCR one. So a `FROM ghcr.io/...` line inside that
+builder resolves against a registry it cannot authenticate to, and the failure is a pull error at
+build time rather than anything a gate here would catch.
+
+Meanwhile GHCR is the right registry for the other consumer: someone reading this README and
+writing a Dockerfile on their laptop, who has a GitHub account and no relationship with any
+product's Azure subscription.
+
+Two consumers, reached by two different credentials. The image has to be in both.
+
+## Decision
+
+The release workflow's `image` job pushes **one build to two registries**:
+
+- **GHCR**, unconditionally, at `ghcr.io/<this repo>` — unchanged.
+- **A product's own registry**, when `vars.PRODUCT_IMAGE` names one. The variable is the full
+  repository path (`<name>.azurecr.io/<product>/foundry-implementation-actor`); the login server
+  is its first segment; `secrets.ACR_PUSH_USERNAME` / `ACR_PUSH_PASSWORD` are the scope-mapped push
+  token `modules/acr` already emits as outputs.
+
+`docker tag` re-points the build GHCR already holds, so both registries carry **one digest**. The
+job does not build twice.
+
+`vars.PRODUCT_IMAGE` unset is a valid state: a fork, or this repo before its credentials existed,
+publishes to GHCR alone and emits a `::notice` saying so. Set-but-broken is a hard failure.
+
+The workflow also gains `workflow_dispatch`, so a version whose wheel is already on PyPI can be
+given an image in a registry it missed without inventing a version number. It **takes the tag as an
+input** and is run from the default branch: GitHub takes the workflow file from the ref it is
+dispatched on, and a tag old enough to need a backfill is by definition older than the workflow
+that can perform one — so the checkout takes its content from the named tag while the file comes
+from the branch. On a manual run the `publish` job is skipped — PyPI refuses a version it already
+holds — and `latest` is **not** moved in either registry, so backfilling an old tag cannot drag it
+backwards.
+
+## Rationale
+
+**Why a variable and not a literal.** This package is generic across capabilities and carries no
+product's name; `tests/test_portability.py` enforces exactly that over `src/`, and a product name
+hardcoded in `release.yml` would be the same mistake one directory over. A product that hosts a
+registry names itself in its own repository variable. It also makes "no product registry
+configured" expressible rather than a broken default.
+
+**Why one build rather than two.** Two `docker build` invocations in one job can produce two
+different images — a base-image tag refreshed between them is enough — and nothing downstream
+would ever notice that `:0.5.0` meant different bytes depending on where it was pulled from. That
+is the same failure the existing gate *the image and the wheel are one release* exists to prevent,
+one level up.
+
+**Why not mirror instead.** ACR can import from another registry (`az acr import`), which would
+keep one publishing path. It needs a credential for the source, which means making the GHCR package
+public or minting a PAT for it, and it puts a second system between the tag and the image. Pushing
+the build we already have in hand is fewer moving parts.
+
+**Why this repo decides this at all.** Where an ecosystem's artifacts live is an `ADR-ECO-*`
+question, and there is no ecosystem ADR about registries today. What this ADR owns is narrower and
+squarely this repo's: that a release publishes to more than one place, and that this package names
+none of them in its own source.
+
+## Consequences
+
+- **Two secrets and one variable must exist** on this repo before the product push does anything:
+  `PRODUCT_IMAGE`, `ACR_PUSH_USERNAME`, `ACR_PUSH_PASSWORD`. The credentials come from
+  `terraform output` on `papeete-platform`'s `examples/acr-local`, and they are set by a human —
+  `papeete-foundry-product/GetSecrets.sh` is TTY-only by design so no credential passes through an
+  assistant's context, and that convention holds here.
+- **0.5.0 shipped to GHCR only.** Its image exists at
+  `ghcr.io/papeete-hub/foundry-implementation-actor:0.5.0` and nowhere else until the manual run
+  above is used to backfill it.
+- **The token's scope map must admit the repository.** `modules/acr`'s `repository_patterns` is the
+  caller's input, and a path outside it is refused at push time with a permissions error rather
+  than at configuration time. Widening it is a `papeete-platform` change, not one here.
+- **A rotated push token silently stops releases.** The token password is created by Terraform with
+  no expiry by default; when that changes, the secret here has to change with it. Nothing in this
+  repo can detect the drift — the first symptom is a failed release job.
+- **Still to realize:** a use's `FROM` line points at GHCR today
+  (`examples/…/Dockerfile`, and the real use in `papeete-foundry`). Pointing it at the product
+  registry is what makes the in-cluster builder work, and it belongs in those repos rather than
+  here — this ADR only makes the image available to be pointed at.