cp_write: true -> state-tx (test-validate@1, frozen-fixture-emit@1) and, in
the archived bug-ancestor-auto-advance@1, tag-set + state-tx.
cp_write: false -> every other script node (verdict-gate, policy-pick,
preflight-*, frozen-fixture-emit, parent-link-check).
tests/invariants/test_cp_write_field_set_correctly.py pins the set.
HOLD: do not merge until the CP release that adds WorkflowNode.cp_write.
The current CP schema is extra="forbid" and rejects the new key
(verified: nodes.0.cp_write extra_forbidden), so on the old CP these
template edits are NOT inert.
Claude-Session: https://claude.ai/code/session_01N218bERyNeLhbLmDRDvbWF
nocp: shared-variables/v1 + repo-readonly/v1 (no CP credential).
write: shared-variables/v1 + cp-write-token/v1 + repo-readonly/v1.
repo-readonly/v1 is last in both (WF-COMP-34); neither layers
cp-service-token/v1 or gitea-ssh/v1.
HOLD: do not merge until the CP release (AU-55/55a/56/57, WF-COMP-31b engine/
dispatch/compiler composite-set changes) and the dispatcher image
(cp-write-token delivery, AU-55b) are deployed. The dispatcher advertises every
composite found in the CRS-synced harnesses/ tree (dispatcher/poller.py
_collect_supported_harnesses), so merging this to origin/main IS the
advertisement event.
Claude-Session: https://claude.ai/code/session_01N218bERyNeLhbLmDRDvbWF
Env-only layer exporting CP_WRITE_TOKEN_FILE=/run/agent/cp-write-token/token.
The per-step wfcw_ token is delivered by the dispatcher into the script
container only (AU-55b), so the layer has no secrets_required, init script or
files. Not referenced by any composite yet; safe to merge at any time.
Claude-Session: https://claude.ai/code/session_01N218bERyNeLhbLmDRDvbWF
repo-readonly/v1 now declares write_targets: [], an ssh_hosts alias and its
own secrets_required (account platform-readonly.space:platform, a read-only
Gitea deploy key), and stages the key before cloning. workflow-script/v1 no
longer layers gitea-ssh/v1, so script nodes cannot push. Invariants updated:
credential layers in the composite must declare write_targets: [].
Bug 45a48685-23e9-4605-af1f-d93306108cef
Claude-Session: https://claude.ai/code/session_01N218bERyNeLhbLmDRDvbWF
The deploy repo NetworkPolicy admits :8100 only from named apps and the traefik/cms-proxy
namespaces; agent/script pods time out, so state-tx / cp-cli calls silently lost transitions.
Invariant now rejects the in-cluster form and pins the ingress URL.
Claude-Session: https://claude.ai/code/session_01N218bERyNeLhbLmDRDvbWF
state-tx exits 2 without CP_URL and STATE_TX_NEW_STATE. Each template's
target state is its own output.state (test-validated / test-skeleton-ready).
Adds an invariant test.
Claude-Session: https://claude.ai/code/session_01N218bERyNeLhbLmDRDvbWF
M2-CRS W4 unblock: dispatched agents could not clone hatchmate/hatchmate-agents
because the shared gitea-ssh/v1 context mounts the ai_enablement deploy key,
which is scoped to skynet/* only. Same bug would hit every project whose
working repo lives outside the skynet org.
This implements the per-org pattern the framework already uses for accelerators
(gitea-ssh-accelerators/v1) and homelab (gitea-ssh-homelab/v1):
- harnesses/contexts/gitea-ssh-hatchmate/v1/{init.sh,harness.yaml} — NEW
forge-credential context mirroring accelerators, with account_ref
'hatchmate.space:platform' and write_targets covering hatchmate/*. The
init.sh stages the ESO-mounted private key to ~/.ssh/gitea-oreillyit-nz-hatchmate
(matching the ssh alias declared in harness.yaml). URL host pattern
'gitea.oreillyit.nz-hatchmate' (per-org alias) drives SSH config block
selection — already auto-written by harness_init.py from each layer's
ssh_hosts: declarations.
- harnesses/composites/code-*-tdd-repo-hatchmate/v1/ — NEW composites for
fable/minimax/airouter/opus that compose BOTH gitea-ssh/v1 (for reference
clones, skynet org) AND gitea-ssh-hatchmate/v1 (for working-repo clone +
push, hatchmate org). Composites are unchanged for non-hatchmate projects.
- tests/invariants/test_forge_credentials_declare_write_targets.py — the
existing xfail(strict=True) marker was wrong: the 4 existing layers all
declare write_targets today, so the test was XPASSing. Removed the
xfail marker so HC-11 is now a real positive gate (5 layers instead
of 4). This was a pre-existing test bug surfaced by the 5th layer.
W4 next step: dispatcher's account_ref resolution needs the hatchmate CP
account + grant to be created (via the new scripts/provision-hatchmate-fork-key.sh
in the hatchmate app repo).
Helper tests/invariants/forge_credentials.py detects credential carriers via
mounts[]/env/secrets_required[]/ssh_hosts[]; today gitea-admin, gitea-ssh,
gitea-ssh-accelerators, gitea-ssh-homelab are found and none declare
write_targets — the invariant xfails(strict) until the CRS-103 rollout stamps them.
Claude-Session: https://claude.ai/code/session_018LRh1S2bHJYhEgrMu3UJx8
