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

foundry_implementation_actor-0.5.1/.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.5.1}/CLAUDE.md

@@ -88,6 +88,11 @@ 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.
 - **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 +109,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.5.1}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: foundry-implementation-actor
-Version: 0.5.0
+Version: 0.5.1
 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.
@@ -329,6 +331,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.5.1}/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.
@@ -306,6 +308,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.5.1}/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.5.1/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.

{foundry_implementation_actor-0.5.0 → foundry_implementation_actor-0.5.1}/adr/README.md

@@ -16,6 +16,7 @@ are named or placed (`ADR-ECO-*` in
 | [ADR-FIA-0003](./ADR-FIA-0003-the-dev-test-agreement-has-no-home-yet.md) | The dev↔test agreement has no home yet — and it is not this actor's to emit | Superseded by 0004 |
 | [ADR-FIA-0004](./ADR-FIA-0004-the-three-amigos-round.md) | The three amigos round — the tester proposes, this actor answers, a human breaks the tie | Accepted |
 | [ADR-FIA-0005](./ADR-FIA-0005-the-actor-ships-an-image.md) | The actor ships an image, and renders its own cards into it — a use is one sidecar | Proposed |
+| [ADR-FIA-0006](./ADR-FIA-0006-the-image-is-published-to-two-registries.md) | The image is published to two registries, and names neither in its source | Proposed |
 
 ## Authoring
 

{foundry_implementation_actor-0.5.0 → foundry_implementation_actor-0.5.1}/examples/ACME.PARTS.CAP.SUP.007.WID-implementation/Dockerfile

@@ -11,7 +11,14 @@
 # The whole ref is one ARG, not just the tag: this repo's own CI builds the base image from the
 # checkout and points this line at it, which is how the example is proven to build against the
 # version being released rather than against the last one published.
-ARG ACTOR_IMAGE=ghcr.io/papeete-hub/foundry-implementation-actor:0.5.0
+#
+# The default names the product registry rather than GHCR for one reason: it is the copy a reader
+# can actually pull. The GHCR package is private, so an unauthenticated `docker build` here fails
+# with a 401 and the example teaches nothing. ACR is where the pull token, the node bypass and the
+# `acr-pull` Secret already point (ADR-FIA-0006 publishes the same digest to both). Override it if
+# you are somewhere else:
+#     docker build --build-arg ACTOR_IMAGE=ghcr.io/papeete-hub/foundry-implementation-actor:0.5.1 .
+ARG ACTOR_IMAGE=papeetefoundry.azurecr.io/foundry/foundry-implementation-actor:0.5.1
 FROM ${ACTOR_IMAGE}
 
 # THE KNOWLEDGE TOOLS THIS SIDECAR NAMES, and the one thing the base image deliberately does not

{foundry_implementation_actor-0.5.0 → foundry_implementation_actor-0.5.1}/examples/README.md

@@ -172,6 +172,22 @@ This runs the real grounding path — fetch, write the envelopes into a clone, r
 `CLAUDE.md`, then check every `@`-import resolves. A session grounded in nothing looks exactly
 like a correctly grounded one, which is why this is a gate rather than a hope.
 
+**4. Build it — this one needs a credential.** The three above run offline; a `docker build` has to
+pull the base image, and both registries that carry it are private. The `ARG ACTOR_IMAGE` default
+names the product registry, so log into that one:
+
+```bash
+ACR_TF=../../papeete-platform/examples/acr-local     # wherever modules/acr was applied
+terraform -chdir="$ACR_TF" output -raw pull_password | docker login papeetefoundry.azurecr.io \
+  --username "$(terraform -chdir="$ACR_TF" output -raw pull_username)" --password-stdin
+
+docker build -t acme-wid-actor ACME.PARTS.CAP.SUP.007.WID-implementation
+docker run --rm acme-wid-actor foundry-implementation-actor lint /actor
+```
+
+The read-only pull token is enough — nothing here pushes. The last line is the interesting one: it
+lints the cards the image actually rendered, which is what a caller will be validated against.
+
 ---
 
 ## What a real request looks like
@@ -233,7 +249,8 @@ docker build -t my-actor . && docker run --rm my-actor foundry-implementation-ac
 ```
 
 The last one is the interesting one: it lints the cards the image actually rendered, which is what
-a caller will be validated against.
+a caller will be validated against. It needs the same registry login as step 4 above — or your own
+`--build-arg ACTOR_IMAGE=`, if you mirror the base image somewhere of your own.
 
 **Embedding it instead.** If you need your own base image, or the actor inside a larger process,
 install the wheel and wire four lines yourself (`assess-task` needs no entry — it is a query with

{foundry_implementation_actor-0.5.0 → foundry_implementation_actor-0.5.1}/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "foundry-implementation-actor"
-version = "0.5.0"
+version = "0.5.1"
 description = "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."
 readme = "README.md"
 requires-python = ">=3.11"

{foundry_implementation_actor-0.5.0 → foundry_implementation_actor-0.5.1}/src/foundry_implementation_actor/engine.py

@@ -569,6 +569,18 @@ class ClaudeCodeEngine:
                if schema else
                " with `feasible` (boolean), `objections` (one entry per expectation you cannot "
                "meet, each naming its `id`) and `commitments` (what you undertake to pin).")
+            # THE ENTRY SHAPE, said in words whether or not a schema was rendered above. The card
+            # types both lists as `list` and stops there, so a rendered schema says nothing about
+            # what goes inside — and a live session, left to choose, answered commitments as
+            # prose strings prefixed "E1: …", which the orchestrating actor cannot attach to the
+            # expectation they name. One object per entry, keyed by the expectation's own `id`.
+            + "\n\nWrite each entry as an object keyed by the expectation it is about:\n"
+            "- `objections`: `{\"id\": \"<expectation id>\", \"reason\": \"...\", "
+            "\"counter_proposal\": \"...\"}` (omit `counter_proposal` when you have none).\n"
+            "- `commitments`: `{\"id\": \"<expectation id>\", \"commitment\": \"<the exact "
+            "value you will pin, and where>\"}` — one entry per expectation, never several ids in "
+            "one entry and never a bare string. A commitment that concerns no single expectation "
+            "takes `\"id\": null`."
         )
         return "\n\n".join(sections)
 
@@ -595,9 +607,14 @@ class ClaudeCodeEngine:
             self.claude_bin, "--print", "--output-format", "stream-json", "--verbose",
             "--append-system-prompt", system,
             "--permission-mode", "acceptEdits",
-            # The assess door passes a list with no Write, Edit or Bash in it. That is the
+            # `--tools`, not only `--allowedTools`. The second merely PRE-APPROVES the tools it names;
+            # every other built-in stays available, and a live assess session was seen reaching
+            # for Bash through it. `--tools` is what removes the rest from the session, so a door
+            # passed a list with no Write, Edit or Bash in it genuinely has none. That is the
             # enforcement, not the prompt's own "you are reading only" — the same discipline as
             # handler.py's containment check standing behind the implement door's write boundary.
+            # Both are variadic: each is followed by another option, never by the prompt.
+            "--tools", allowed_tools,
             "--allowedTools", allowed_tools,
             "--max-turns", str(max_turns),
             situational_prompt,

{foundry_implementation_actor-0.5.0 → foundry_implementation_actor-0.5.1}/tests/test_engine.py

@@ -7,6 +7,7 @@ hardcoded, and that no line it emits can exceed the budget Loki rejects outright
 from __future__ import annotations
 
 import json
+import sys
 from pathlib import Path
 
 import pytest
@@ -190,6 +191,18 @@ def test_the_answers_shape_is_the_cards_own_when_one_is_given(engine):
     assert "`feasible` (boolean)" in without
 
 
+def test_every_entry_is_keyed_by_the_expectation_it_is_about(engine):
+    """A live assess session answered commitments as prose strings ("E1: …", "E4/E5: …"), which
+    the orchestrating actor could not attach to anything. The card types the lists and no more,
+    so the shape is said in words — with a schema rendered and without."""
+    schema = {"properties": {"feasible": {"type": "boolean"}}, "required": ["feasible"]}
+    for prompt in (engine._assessment_prompt(PAYLOAD, schema),
+                   engine._assessment_prompt(PAYLOAD, None)):
+        assert '`{"id": "<expectation id>", "commitment":' in prompt
+        assert '`{"id": "<expectation id>", "reason":' in prompt
+        assert "never a bare string" in prompt
+
+
 def test_an_empty_surface_is_said_out_loud(engine):
     """A caller that proposed nothing gets asked what it expected, rather than a bare yes."""
     assert "empty" in engine._assessment_prompt(PAYLOAD, None)
@@ -267,6 +280,34 @@ def test_the_assess_session_is_given_no_tool_that_writes(assessed):
     assert IMPLEMENT_TOOLS != ASSESS_TOOLS
 
 
+FAKE_CLAUDE = """
+import json, sys
+open(sys.argv[0] + ".argv", "w").write(json.dumps(sys.argv[1:]))
+print(json.dumps({"type": "result", "subtype": "success", "is_error": False, "result": "done"}))
+"""
+
+
+def test_the_tool_list_removes_tools_rather_than_only_approving_some(config, tmp_path,
+                                                                    monkeypatch):
+    """`--allowedTools` only pre-approves what it names; every other built-in stays available,
+    and a live assess session reached for Bash through it. `--tools` is what takes the rest
+    away, so it has to carry the same list — and, being variadic, never sit last."""
+    script = tmp_path / "claude"
+    script.write_text(f"#!{sys.executable}\n{FAKE_CLAUDE}")
+    script.chmod(0o755)
+    monkeypatch.setenv("GIT_CONFIG_GLOBAL", str(tmp_path / "gitconfig"))
+    engine = ClaudeCodeEngine(config, github_token="ghs_fake", claude_bin=str(script))
+
+    assert engine._invoke_claude(tmp_path, "system", "THE PROMPT",
+                                 allowed_tools=ASSESS_TOOLS) == "done"
+    argv = json.loads((tmp_path / "claude.argv").read_text())
+
+    assert argv[argv.index("--tools") + 1] == ASSESS_TOOLS
+    assert argv[argv.index("--allowedTools") + 1] == ASSESS_TOOLS
+    assert argv[-1] == "THE PROMPT"
+    assert argv[argv.index("--tools") + 2].startswith("--")
+
+
 def test_the_assess_session_gets_a_smaller_budget(assessed, engine):
     _, seen = assessed('```json\n{"feasible": true}\n```')
     assert seen["max_turns"] == engine.assess_max_turns < engine.max_turns

{foundry_implementation_actor-0.5.0 → foundry_implementation_actor-0.5.1}/uv.lock

@@ -18,7 +18,7 @@ wheels = [
 
 [[package]]
 name = "foundry-implementation-actor"
-version = "0.5.0"
+version = "0.5.1"
 source = { editable = "." }
 dependencies = [
     { name = "papeete-actor-synchronous-messaging" },

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

@@ -1,106 +0,0 @@
-name: release
-on:
-  push:
-    tags: ["v*"]
-
-# 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:
-    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
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v4
-      - 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.
-        id: version
-        run: |
-          tag="${GITHUB_REF_NAME#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 $GITHUB_REF_NAME 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
-        run: |
-          image="ghcr.io/${{ github.repository }}"
-          docker build -f docker/Dockerfile \
-            -t "$image:${{ steps.version.outputs.version }}" \
-            -t "$image:latest" .
-          docker push "$image:${{ steps.version.outputs.version }}"
-          docker push "$image:latest"
-
-      - 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