Warn when a provider env map sets ANTHROPIC_BASE_URL, API_TIMEOUT_MS, HOME or RUNNER_TEMP

[The01Geek]

Problem Statement

A maintainer sets up a third-party model provider in .prflow/config.json. That provider entry has dedicated fields for the endpoint (base_url) and the request timeout (timeout_ms), and a free-form env map for anything else. If the maintainer puts ANTHROPIC_BASE_URL or API_TIMEOUT_MS in the env map, it quietly beats the dedicated field, and nothing in the run says so. Two names that are not written by the step at all, HOME and RUNNER_TEMP, are just as unguarded, and setting one of them moves where every later step in the job looks for its files.

This is a config footgun, not a security hole. .prflow/config.json is maintainer-owned and read from a trusted branch, and the two names that would matter for credentials are already refused.

Current Behavior

Triggering input. A provider entry whose env map names any of ANTHROPIC_BASE_URL, API_TIMEOUT_MS, HOME or RUNNER_TEMP.

Observed result. The "Inject provider endpoint" step exits 0 and prints nothing. It writes its own values first and appends the env map last, so the map's value is the one later steps see. On the Bedrock path the run contradicts itself: the step warns that base_url is ignored, while the map puts an endpoint back.

Expected result. A warning naming the keys, so the maintainer can see that the env map decided the value.

Environment. All three cloud workflows, on the GitHub-hosted Actions runner. The defect does not depend on the operating system or the shell.

Desired Behavior

The step keeps working exactly as it does today, and adds one warning. When a provider env map names any of the four watched keys, the step prints a single ::warning:: listing every matched key and carries on. Which value ends up in effect does not change: the env map still wins, deliberately, so no existing setup breaks.

User Impact

A maintainer who sets one of these keys in the env map finds out from the run log instead of from surprising behavior. Everyone else sees no change: a run whose env map names none of the four keys behaves and logs exactly as before.

Technical Context

Scope note: The files and details below are the known starting points, not the full list. Before implementing, trace the change through the codebase to find every affected call site, consumer, and layer — this issue maps the work, it does not bound it.

• Relevant Classes/Files — the "Inject provider endpoint (provider-routed sections only)" step, which is byte-identical in .github/workflows/devflow.yml, .github/workflows/devflow-implement.yml and .github/workflows/devflow-runner.yml; the #1773 block in lib/test/run.sh.

• Architecture Alignment — a new warn block beside the existing guards in the same step, mirroring the shape of the deny guard directly above it. No new file, no new helper, no config key.

• Execution tier — the block runs inside a workflow run: step, executed by the Actions runner rather than by the model action. No tool-permission allowlist and no command-shape matcher sits in front of it, so the change adds no grant and cannot be silently denied. The allowlist the workflow does build is assembled in a different step and is untouched.

• How consumers get it — the installer already copies these three workflow files, so a consumer picks the change up by re-running the installer. Nothing in install.sh changes.

• Dependencies — none beyond what the step already uses (jq).

• Data/Schema Considerations — .prflow/config.schema.json describes the provider env map and lists the names the deny guard refuses; the four watched keys are not there yet and the description gains them. The schema's shape does not change.

• Cross-layer Impact — three workflow files, one test block, and four documentation surfaces.

• Verified: .prflow/config.schema.json states the ordering the whole problem rests on: "The env map is written last in the step, so an accepted key takes effect for every subsequent step in the job, not just the action step."

• Verified: lib/test/modules/coverage-map.json names the covering test run for this surface: "issue The provider env map is exported unfiltered and needs a deny list #1773 provider env-map key-name deny list; run.sh-resident, driven from the R313_INJ_BODY inject-step extraction beside the Add opt-in third-party model provider support to the cloud tier (per-workflow endpoint, auth, and model selection) #313 assertions (the monolith shard covers them)".

• Third-party behavior, with its source: the Actions runner stores each GITHUB_ENV pair by assigning into a dictionary in SetEnvFileCommand, so a later write for the same key replaces an earlier one. Source: https://raw.githubusercontent.com/actions/runner/main/src/Runner.Worker/FileCommandManager.cs — the published documentation at https://docs.github.com/en/actions/reference/workflows-and-actions/variables does not cover repeated writes.

• Setting HOME moves where the model action writes its user settings file, and where gh and git read their configuration in the steps that follow — assumption, confirm before implementing, citing the in-repo comment in .github/workflows/devflow-implement.yml that records reading the action's source and concluding it resolves the user settings path from the home directory.

• RUNNER_TEMP is read by name by later steps in all three workflows, among them the git-env pin resolution, the committer identity resolution, the execution-transcript scrub and the observability backstop.

• Builds on The provider env map is exported unfiltered and needs a deny list #1773, merged, which added the deny guard this change deliberately leaves alone. The provider env deny list omits the names the inject step writes itself #1892 was recorded there as deferred.

Acceptance Criteria

• The watched keys are exactly these four — complete by construction: ANTHROPIC_BASE_URL, API_TIMEOUT_MS, HOME, RUNNER_TEMP. When a provider env map names one or more of them, the step prints one ::warning:: naming every key that matched, and exits 0.
• A key the env map sets ends up with the map's value, for the watched keys and every other key alike, unchanged from before this issue: an existing provider configuration produces the same GITHUB_ENV contents it produces today, plus the new warning line.
• Key matching is case-folded and whole-name, the same rule the deny guard directly above already applies: a map naming home warns exactly as one naming HOME does, and a map naming HOMEDIR produces no warning.
• A provider env map naming none of the four watched keys produces no warning, and the step's output is unchanged from before this issue.
• Every name the deny guard refuses today still refuses the run with the same ::error::, and the deny guard's list of names is unchanged.
• The "Inject provider endpoint" step body is byte-identical across the three workflow files after the change, the property the existing three-way body-identity check asserts.
• The test block's per-key refusal loop covers the deny guard's names and none of the four watched keys, so no watched key is asserted to refuse the run.
• A provider entry with no env key at all, and one whose env is not an object, behave exactly as they do today — the new warn block does not introduce a new way for the step to fail.

Implementation Notes

• Approach — add one warn block to the "Inject provider endpoint" step, beside the guards that already run there. It reads the env map's keys, upper-cases each one and tests it against a four-name set, collects the matches, and prints a single ::warning:: naming them. It reports and continues rather than refusing the run, and it changes neither what is written nor the order it is written in. Every name outside the four is handled by the path that handles it today: the step's final statement exports it verbatim, with no warning. The deny guard, the name-shape guard and the empty-secret guard are all untouched, and no name moves onto the deny list.

  The same change narrows how the test block finds the denied names. That extraction currently scans the whole step body for a line containing the membership test, and the new warn block adds a second such line, so the extraction is anchored to the deny guard's own assignment. Without that, the watched keys are swept into the loop that asserts a name refuses the run, and the suite fails on names that are meant to warn.

• Relevant files — the three workflow files carrying the step (.github/workflows/devflow.yml, .github/workflows/devflow-implement.yml, .github/workflows/devflow-runner.yml), which must be edited together to stay byte-identical; the #1773 block in lib/test/run.sh for the new assertions; likely .prflow/config.schema.json and docs/external/docs/configuration/providers.md, and plausibly docs/internal/cloud-setup.md and docs/internal/DEVFLOW_SYSTEM_OVERVIEW.md, for the prose copies; and a new .changeset/*.md file.

• Code Patterns — copy the deny guard that sits directly above: the same jq shape reading .env // {}, the same ascii_upcase | IN(...) membership test, the same collect-then-report-once form that names every offending key in one message. Keep the command substitution in a bare assignment, exactly as denied_env_keys does and for the same reason the comment beside it gives.

• Testing Strategy — extend the #1773 block in lib/test/run.sh, which extracts the real step body and runs it under bash -c against a temporary GITHUB_ENV. That single behavioral level is the whole plan; there is no unit boundary below it and no integration boundary above it.

  Start with the bug-reproduction case: feed a map naming ANTHROPIC_BASE_URL and assert no warning is printed. That fails against today's code by exhibiting the reported silence, and passes once the warn block lands.

  The warned names are not covered for free. The existing per-key loop derives its population from the deny guard's own list, so it sweeps up denied names automatically and will not touch a warned one. Every case below is hand-written.

  Cases to add: one per watched key, asserting the warning names it and the step still exits 0; two keys at once, asserting a single warning names both; a lower-case spelling, asserting it matches; a longer name containing a watched key, asserting it does not; a map naming none of the four, asserting silence; and the Bedrock path with ANTHROPIC_BASE_URL in the map, which is the case where the step's existing "base_url is ignored" warning and the map disagree.

  These shape cases guard the new block itself: a provider entry with no env key, and one whose env is not an object. Both must behave as they do today.

  governing conventions consulted: CLAUDE.md (the six-shape adversarial matrix for config-JSON consumers), CONTRIBUTING.md, and docs/internal/. The six-shape matrix is deliberately narrowed here to the two shapes above. The justification: the new block reads the same .env value the deny guard already reads, through the same .env // {} guard, so the array, scalar and valid-falsy shapes reach it exactly as they reach the existing guard and are already covered there. Only the absent and non-object shapes exercise the new block's own reading of that value.

• Documentation Needed — .prflow/config.schema.json, docs/external/docs/configuration/providers.md, docs/internal/cloud-setup.md, docs/internal/DEVFLOW_SYSTEM_OVERVIEW.md. Each gains the four watched keys and the warn-do-not-refuse rule, kept clearly apart from the deny list so a reader does not take a warned key for a refused one. While editing docs/internal/cloud-setup.md, correct the sentence introducing that bullet: it promises two notes above three bullets, and it says the schema carries none of the content when the schema in fact carries the whole name inventory.

• Potential Gotchas

  • The command substitution must be a bare assignment. Wrapping it in local, declare, or an if/&&/|| context lets set -e swallow a jq failure, and the empty result then reads as "nothing matched" — the warning silently never fires. The deny guard above carries a comment saying exactly this.
  • The test block derives the denied names by scanning the extracted step body for the membership test and printing every line that matches. A warn block written with the same shape puts the watched keys into that population, and the per-key loop then asserts each one refuses the run with an empty GITHUB_ENV file. They warn and continue, so the suite fails. Anchor the extraction to the deny guard's assignment before adding the block. The extraction already fails closed if it matches nothing at all, because the frozen list of expected names is then reported missing in full.
  • The three step bodies are asserted byte-identical, comparing the run: bodies only. Editing one file and not the others turns the suite red; the differing SECTION value lives in the step's env: block and is outside that comparison.
  • The suite cannot check which of two writes wins. Its GITHUB_ENV helpers emit every occurrence of a repeated key rather than resolving a winner, and every assertion over that output is a membership test. So assert the warning fires; do not try to assert precedence.
  • The four watched names will exist as one executable copy plus several prose copies, and no test reconciles them. This already happened to the deny list, where only the workflow copy is machine-checked, so a name added there keeps the suite green while every prose copy drifts.
  • Editing files under .github/workflows/ needs a workflows-scoped push.
  • The covering run for this surface is lib/test/run-shard.sh monolith; there is no focused module.
  • The change adds a .changeset/*.md file with a patch bump. Nothing starts refusing, so no consumer action is required on upgrade — unlike The provider env map is exported unfiltered and needs a deny list #1773, which shipped as a minor with an upgrade note precisely because it made runs fail.

Generated via /prflow:create-issue (v2.34.2, claude-opus-5, high)

[The01Geek]

Investigation record

How this ticket changed during refinement, and what was checked to get there. None of this is part of the implementation contract in the issue body.

Two of the original three questions were malformed

The original ticket named three environment-variable names and asked three questions.

• "Deny all three, or only the two the step writes?" is a false dichotomy. The real family is larger than three, and its members do not behave alike, so neither offered branch was a resolved decision.
• "Group HOME with the interpreter/loader-hook class, or give it its own?" offers two branches when the answer is neither. HOME belongs to the existing shadows the job environment group, which already holds PATH and the GITHUB_* names. The class that would actually need inventing is one for names the step computes from a dedicated field — and that class covers ANTHROPIC_BASE_URL and API_TIMEOUT_MS, which the question never reached.
• Only the escape-hatch question was well formed, and it is the one the operator answered.

RUNNER_TEMP was added to the set

It sits in exactly the same position as HOME: not denied, passes the name-shape guard, exported to every later step. Four later steps in each of the three workflows read it by name — the git-env pin resolution, the committer identity resolution, the execution-transcript scrub, and the observability backstop. A step-index walk of the workflows found it. The original ticket did not name it.

A wider family was found and deliberately left out

GH_CONFIG_DIR, GIT_CONFIG_GLOBAL, XDG_CONFIG_HOME and CLAUDE_CONFIG_DIR are read implicitly — no step body mentions them, because the tool reads them from its own environment. Later steps do run those tools: gh at steps 18 and 27 and git at steps 18 and 25 of the implement workflow.

That list rests on which tools happen to run after the step today, and nothing in the repository enumerates what an external tool reads from its environment, so it cannot be shown complete. The operator scoped the change to the four names with a proven reader and left this family out.

GITHUB_WORKSPACE was considered and ruled out on evidence: it is referenced only in the config job, which runs before and outside this job's environment, so this path cannot reach it.

The central premise was unverified in this repository, and is now grounded

The whole ticket rests on "a later line written for the same key wins". That is asserted nowhere in this repository. The test suite's own helpers for reading the environment file emit every occurrence of a repeated key rather than resolving a winner, and every assertion over that output is a membership test — so no in-tree assertion would have gone red if precedence ran the other way.

The published platform documentation does not cover repeated writes either; the documentation rungs of the verification ladder returned nothing. It was settled at the vendor's own implementation instead: the runner stores each pair by assigning into a dictionary, so a later entry for the same key replaces the earlier one. That source is cited in the issue body.

A build-breaker was caught before filing

The test block finds the denied names by scanning the extracted step body for the membership test and printing every line that matches. Because the operator chose case-folded matching "like the deny guard", the natural warn block writes a second such line. Those four watched keys would then be swept into the loop that asserts a name refuses the run with an empty environment file — and they warn and continue, so the suite would fail on names that are meant to warn.

The fix — anchor the extraction to the deny guard's own assignment — is part of the approach in the issue body rather than a surprise for the implementer.

Mechanisms considered and passed over

• Reverse the emit order, so a dedicated field always beats the passthrough map. The strongest deterministic option, and the one the original ticket never mentioned. Ruled out twice over: the operator chose to keep the override working, and it does nothing for HOME or RUNNER_TEMP, which the step never writes.
• Deny all four. Ruled out by the same decision. It would have been the cheapest to test, because the existing per-key loop covers a denied name with no test written at all.
• Arm-sensitive collision detection — warn only where the step actually wrote the name on this auth arm. Rejected on analysis: on the Bedrock arm the step writes no endpoint variable at all, which is precisely the contradiction case, so arm-sensitivity would exempt the worst instance.
• Considered-and-rejected: 2 heavier candidate(s) — a schema-level or resolver-level filter (the schema has no runtime reader and the resolver's only rejection idiom is an error marker, so both would be silent).

Documentation defects found nearby

The internal cloud-setup page promises "two operational notes the schema does not carry" and then lists three bullets — and the schema does in fact carry the whole name inventory it says is missing. That sentence introduces the very bullet this change edits, so the correction rides along.

Out of scope, worth its own ticket: the same page names the light command path's configuration section devflow, but the workflow sets that section to prflow. Under this repository's rename policy the mismatch is detected rather than read through, so a maintainer following the page gets a warning and a silent default. Different paragraph, different bug.

Release handling

Nothing starts refusing, so this is a patch-level change with no upgrade note. The predecessor shipped as a minor release with an "action required" note precisely because it made runs fail; this one does not.

What was checked

• Three documentation-verification passes: one over the whole tracked tree, then two over disjoint halves after the first returned an unreliable signal. The second pair corrected the first on one point — there is no canonicality loop, but there is a canonical-home contradiction, with three surfaces carrying the same name list and none of them unambiguously the home.
• The shipped step body was extracted and executed against a temporary environment file, which is how the override, the Bedrock contradiction, and the two unguarded names were demonstrated rather than inferred.
• Nine referenced paths confirmed to exist; both quoted premises confirmed verbatim against their files; all four mechanism dependencies confirmed present in the surfaces that own them.

[The01Geek]

/prflow:implement 1911

[github-actions]

PRFlow Workpad — Issue #1911

Status: 🎉 Complete
Branch: issue-1911-warn-when-a-provider-env-map-sets-anthropic-base
Run: View run
PR: #1919
Last updated: 2026-08-25 02:48 UTC

Progress

• Setup — branch & workpad
  • prompt extension resolved: implement
  • 20:40:59 — /prflow:implement run started
  • 20:41:42 — Claude job setup complete; invoking agent
  • 20:44:25 — agent entered Phase 1 setup; workpad triage passed
  • 20:44:32 — agent initialized; Phase 1 workpad hydrated
  • 20:44:49 — resume-kind: fresh
  • 20:44:49 — classification: non-bug — content requests a new warning capability, not a malfunction; explicitly a config footgun not a security hole, so no reproduction is owed
  • 20:45:05 — Phase 1.3.5: early dependency preflight passed (PROCEED)
  • 20:47:11 — issue-claim audit (projection): every Desired Behavior obligation is represented in the resolved acceptance criteria — pass complete
  • 20:47:13 — issue-claim audit (count): claimed '3 workflow files' and '4 watched keys', verified 3 workflow files carry the step and the deny-guard list matches at HEAD
  • 20:47:15 — issue-claim audit (negative-scope): issue excluded new file/helper/config key and install.sh changes; trace confirms no impact
  • 20:47:17 — issue-claim audit (policy): AC/notes' patch bump aligns with .prflow/prompt-extensions/implement.md
  • 20:47:19 — issue-claim audit (execution-capability): credential is workflow-capable (cloud tier, DEVFLOW_APP_ID non-empty) — workflow-file ACs are pushable by this run; no deferral
  • 20:47:21 — issue-claim audit (verified-premise): re-checked 2 Verified: bullet(s) at HEAD — 2 hold, 0 unestablished; no premise refuted
  • 22:37:23 — /prflow:implement run resumed from stall-backstop terminal status; Phase 1 workpad hydrated
  • 22:37:37 — resume-kind: in-flight
  • 22:38:01 — checkpoint (resume): merged origin/main and pushed (was behind by 4); clean ort merge, only docs/changelog arrived — no contract overlap with the inject-step warn block
  • 02:35:28 — resume-kind: in-flight
  • 02:35:28 — local /prflow:implement run resumed; Phase 1 workpad hydrated (the 💥 Failed status was the cloud stall backstop's write over an in-flight run, not an operator terminal)
  • 02:35:28 — Phase 1.3: Acceptance Criteria deliberately NOT replaced this entry — the parsed acs file is byte-identical to the workpad rows and a replace would discard the Phase 3.4 two-verifier tick state that this resume relies on
• Implement
  • code + sweeps
  • 20:48:07 — entered Phase 2
  • 20:50:07 — Phase 2 discovery done inline (fully-specified contained change): read the Inject-provider-endpoint step in .github/workflows/devflow-implement.yml (deny guard at run.sh:959 / step body) and the The provider env map is exported unfiltered and needs a deny list #1773/Add opt-in third-party model provider support to the cloud tier (per-workflow endpoint, auth, and model selection) #313 test harness in lib/test/run.sh. Path A (simple). Reuse+altitude gate: warn block reuses the deny guard's exact jq shape (.env // {} | ascii_upcase | IN(...)) — no new helper; correct altitude (a peer guard beside the existing guards).
  • 20:50:07 — Coupled-site map (searches run: Grep 'Inject provider endpoint' -> 4 files; Grep '1773' in run.sh): executable copy = the byte-identical run body in .github/workflows/{devflow.yml,devflow-implement.yml,devflow-runner.yml}; test = The provider env map is exported unfiltered and needs a deny list #1773 block lib/test/run.sh (R1773 extraction + per-key loop); prose copies = .prflow/config.schema.json + 4 docs surfaces (no test reconciles the four names across prose — accepted, same as deny list).
  • 20:50:23 — Criterion-lifecycle accounting (all 8 ACs → Testable, RED/GREEN in the The provider env map is exported unfiltered and needs a deny list #1773 bash -c harness, lib/test/run.sh): AC1 watched-keys-warn+exit0; AC2 map value still wins (membership assertion, gh_kv) + AC1 covers the warning-added; AC3 case-fold + whole-name (home warns, HOMEDIR silent); AC4 none-of-four silence; AC5 deny guard unchanged (existing The provider env map is exported unfiltered and needs a deny list #1773 per-key refusal loop still GREEN); AC6 three-way byte-identical body check (existing); AC7 per-key refusal loop covers only deny names, no watched key — verified by anchoring R1773_KEYS extraction to denied_env_keys= line; AC8 no-env-key and non-object .env shape cases. Covering run: lib/test/run-shard.sh monolith (no focused module).
  • 20:50:23 — test-first: lib/test/run.sh The provider env map is exported unfiltered and needs a deny list #1773 block — new warn-block assertions written RED (today the step prints no ::warning::) then GREEN after the workflow warn block lands. Sweep selection: add-only diff to inject-step + test + (Phase 4) prose; enum-addition to a doc-enumerated set (the watched-key inventory across prose copies) -> run always-on sweeps 2.3.3/2.3.4/2.3.4a/2.3.4b/2.3.5/2.3.6, plus 2.3.0b (adds members to an enumerated key set with prose mirrors) and 2.3.0c (adds a guard/policy block).
  • 21:10:07 — Sweep 2.3.0a peer-checkpoint: classification = co-locatable peers (three byte-identical workflow run bodies). Search (Grep warned_env_keys) = 4 files: all 3 workflows carry the warn block + lib/test/run.sh references it. Peer set complete; the three-way byte-identity check (AC 6) mechanically enforces it. No exemptions.
  • 21:10:07 — Sweep 2.3.0b enum-enumeration: watched set = ANTHROPIC_BASE_URL, API_TIMEOUT_MS, HOME, RUNNER_TEMP. Search of the IN literal = exactly 3 workflows (the executable enumeration); test R1911_EXPECTED reconciled. Doc-mirror enumerations (schema + 4 docs) are the intended add sites, deferred to Phase 4.1 documentation; they do not yet name the set, so nothing stale in this PR.
  • 21:10:07 — Sweep 2.3.0c operand-trace (code guard): comparand = warned_env_keys, tested by the -n check. Producer = the bare jq assignment on the line directly above, run unconditionally before the auth branch (emitted on every path). Only a present watched key yields a non-empty value; no other cause. Derived (jq) malformed arms: the deny guard runs the SAME .env // {} jq FIRST, so any shape that would fault warn jq (non-object .env) already aborts at the deny guard under set -e (bare assignment) — verified by the AC8 non-object test. null/missing/false .env resolve via // {} to no keys, no warn. No fail-open arm.
  • 21:10:07 — Always-on sweeps: 2.3.3 touched code portable + bare-assignment convention (matches deny guard); no new .py/.sh so no SPDX. 2.3.4 workflow addendum: (a) endpoint-permission — warn block adds no gh api call, no new endpoint/permission; (b) event-path artifact — no new event path, no check-run/status/comment, the warning is a log annotation with no reader. External-output: matches the ::warning:: workflow-command literal (stable) + standard jq ascii_upcase/IN. 2.3.4a self-authored claims (written-last-wins + bare-assignment comments; test RED-on-mutation comments) traced to shipped behavior, no divergence. 2.3.4b stale-prose-lint on merge-base branch delta = 0 rows exit 0; no new untracked file yet. 2.3.5 warn block minimal, reuses deny-guard shape. 2.3.6 error handling: bare assignment fails closed under set -e; reports-and-continues by design (the AC); breadcrumb names the specific keys; jq is preflight-guaranteed.
  • 21:10:07 — test-first RED/GREEN evidence: current inject body (pre-edit, extracted) ran with an ANTHROPIC_BASE_URL env map and printed NO ::warning::, exit 0 (the reported silence = RED). Post-edit body printed one ::warning:: naming the key, exit 0 (GREEN). Full monolith shard: 9913 passed, 0 failed, 1 skipped (the expected Scope the stale-prose lint to comment/prose lines (claim AND R4 permit referent) #434 dirty-tree stale-prose gate). All 17 Warn when a provider env map sets ANTHROPIC_BASE_URL, API_TIMEOUT_MS, HOME or RUNNER_TEMP #1911 assertions PASS; the The provider env map is exported unfiltered and needs a deny list #1773 deny-loop still covers only the 21 deny names (extraction anchored to denied_env_keys=).
  • 22:21:51 — run died: fail-exhausted — https://github.com/The01Geek/prflow/actions/runs/32784175299
  • 22:33:10 — trigger accepted; existing workpad adopted
  • 22:33:49 — Claude job setup complete; invoking agent
• Review
  • prompt extension resolved: review engine
  • prompt extension resolved: fix loop
  • prompt extension resolved: code-review reception
  • Classify diff (Phase 0.5)
  • Generate verification checklist (Phase 1)
  • Verify checklist (Phase 2)
  • Review agents (Phase 3)
  • Aggregate & verdict (Phase 4)
  • Run complete — everything this run owed
  • /simplify
  • review-and-fix
  • acceptance-criteria gate
  • 21:12:41 — Versioning: added .changeset/issue-1911-warn-provider-env-map-keys.md, bump=patch (issue authorizes patch; nothing starts refusing), type=Added. Committed after draft PR Warn when a provider env map sets ANTHROPIC_BASE_URL, API_TIMEOUT_MS, HOME or RUNNER_TEMP #1919, before the review pass.
  • 21:53:25 — trigger accepted; existing workpad adopted
  • 21:54:10 — Claude job setup complete; invoking agent
  • 21:56:18 — run 32781839046 resumed in-flight at Phase 3.3 (prior attempt completed Phases 1-2, draft PR Warn when a provider env map sets ANTHROPIC_BASE_URL, API_TIMEOUT_MS, HOME or RUNNER_TEMP #1919, /simplify); feature branch checked out clean
  • 21:56:18 — /prflow:implement run resumed; continuing at Phase 3.3 review-and-fix
  • 21:56:39 — mid-phase resume point recorded
  • 21:57:44 — /simplify: 4 cleanup agents (reuse/simplification/efficiency/altitude) all returned clean; no changes to commit
  • 21:58:15 — checkpoint 2 (pre-review): merged origin/main and pushed (was behind by 22); auto-merged run.sh + coverage-map.json cleanly, no conflicts
  • 21:58:32 — Phase 3.3: invoking review-and-fix in PR mode with draft PR Warn when a provider env map sets ANTHROPIC_BASE_URL, API_TIMEOUT_MS, HOME or RUNNER_TEMP #1919 (bare token) --push-each-iteration --issue 1911
  • 22:07:08 — Phase 2: 12 checklist items verified — 11 PASS. VC-6 (three-way body-identity covers inject step) returned FAIL from the verifier, but orchestrator direct verification refutes it: lib/test/run.sh:32382-32404 R313_BODY_IDENT YAML-parses the inject-step run body across all three workflows (names[] includes 'Inject provider endpoint (provider-routed sections only)') and asserts b[0]==b[1]==b[2] == 'yes'. AC6 satisfied; verifier missed R313_BODY_IDENT, seeing only R313_INJ_BODY. Net: 12/12 verified.
  • 22:20:45 — trigger accepted; existing workpad adopted
  • 22:21:20 — Claude job setup complete; invoking agent
  • 22:38:44 — Phase 3.3 (resume): invoking review-and-fix in PR mode, PR Warn when a provider env map sets ANTHROPIC_BASE_URL, API_TIMEOUT_MS, HOME or RUNNER_TEMP #1919 bare token --push-each-iteration --issue 1911; pre-loop iter snapshot empty (fresh cloud checkout)
  • 23:00:33 — Phase 3.3 review-and-fix converged (Decide outcome 1): loop-verdict CLEAN-FULL, APPROVE WITH ADVISORY NOTES, shadow agreed full coverage (5 reviewers). Engine + shadow ran as fanned-out subagents; all three review extensions loaded content-present (observed whole output). 1 Important finding refuted (claim-quality: body self-sets set -euo pipefail; shadow independently confirmed), 1 Suggestion + 2 shadow Suggestions advisory. No fixes owed. Post-shadow edit gate: HEAD moved only by Checkpoint-3 base merge that added nothing to the PR diff; warn block byte-identical across all 3 workflows.
  • 23:20:53 — 3.4 gate: two-verifier reconciled satisfied for all 8 non-post-merge criteria; evidence and dispositions in this run's AC dispositions note
• Documentation
  • 23:22:05 — Phase 4.1: extractor span-suppression breadcrumbs are not durably observable on the cloud tier (stderr not captured); a suppressed command/grant literal in the Documentation Needed block leaves no run-record trace
  • 23:27:10 — 4.2 claim audit (behavioral): checked — warn block after deny guard, warns-and-continues, env map value still wins; body matches shipped code, no overclaim
  • 23:27:10 — 4.2 claim audit (verification): checked — Test Plan bound to the Warn when a provider env map sets ANTHROPIC_BASE_URL, API_TIMEOUT_MS, HOME or RUNNER_TEMP #1911 lib/test/run.sh additions; covering run named as lib/test/run-shard.sh monolith (no focused module); no whole-suite-green claim
  • 23:27:10 — 4.2 claim audit (artifact-existence): checked — changeset + 4 doc surfaces all resolve in this PR; no follow-up issue referenced (none owed)
  • 23:27:10 — 4.2 PR body updated from placeholder (confirmed); no code-level fix made (body-side reconciliation only)
  • 23:30:22 — batched-regeneration: run (bare + --with-floors both clean, all artifacts reconciled exit 0, exact-module-floors match; no drift to commit)
  • 00:18:33 — run died: fail-exhausted — https://github.com/The01Geek/prflow/actions/runs/32785157685
  • 00:18:37 — empty branch: could not establish whether any commit reached the remote branch — the base ref origin/main could not be fetched from origin (remote unreachable or base absent). The branch may or may not carry work; this is not a confirmed no-commit outcome. — https://github.com/The01Geek/prflow/actions/runs/32785157685
  • 02:40:47 — checkpoint 4 (resume): observed token UPDATED 58 — merged origin/main and pushed; new head 653b81d. Clean ort merge, no conflicts; the read-target and cross-pass-coherence rules are discharged for the remainder of this run.
  • 02:40:47 — batched-regeneration: skipped — the bare pass reconciled every row clean (exit 0), but the --with-floors pass returned INFRASTRUCTURE / exit 2 on the exact-module-floors row: module create-issue-contract reported 'skip-assertion credit met or exceeded the assertion floor 1 and was rejected', caused by the create-issue Step 4 listing: report presence from what the shell shows, not from a row existing #1733 host-capability skip (busybox absent on this macOS host). That floor row is therefore UNCHECKED here, not clean; CI's test_module_runner.py equality assertion is the checking surface. No writing row left drift — the tree is clean.
  • 02:40:47 — Phase 4.1 (resume): applied the Documented label to PR Warn when a provider env map sets ANTHROPIC_BASE_URL, API_TIMEOUT_MS, HOME or RUNNER_TEMP #1919; the four documentation surfaces (config.schema.json, docs/external/docs/configuration/providers.md, docs/internal/cloud-setup.md, docs/internal/DEVFLOW_SYSTEM_OVERVIEW.md) already landed on the branch in the prior attempt, but the label had not been applied before that run died.
  • 02:46:06 — completion evidence recorded from CI reading (head 653b81d…, https://github.com/The01Geek/prflow/actions/runs/32802043373, validated)
  • 02:47:38 — UP_TO_DATE — branch level with origin/main at 653b81d; no merge or push made, so the CI reading for that head still binds
  • 02:47:58 — review-coverage record restored: this resume's Phase 1.3 --strip-inherited-checkpoints cleared the row the prior attempt wrote at 23:00:20 (coverage=full, dispatch=attempted, roster=complete, checklist=complete, from the Phase 3.3 review-and-fix exit: loop-verdict CLEAN-FULL, APPROVE WITH ADVISORY NOTES, shadow agreed full coverage over 5 reviewers). The values are that attempt's own, not re-derived here; the review itself is unchanged and its PR diff has not moved since.
  • 02:47:58 — review coverage recorded (coverage=full, dispatch=attempted, roster=complete, checklist=complete)
• PR marked ready
  • 02:48:06 — Phase 4.3: working tree asserted clean; PR Warn when a provider env map sets ANTHROPIC_BASE_URL, API_TIMEOUT_MS, HOME or RUNNER_TEMP #1919 published with gh pr ready (prflow_implement.implement_pr_state=ready_for_review). Completion gate discharged by the CI reading for head 653b81d — both required checks green.

Plan

• Anchor the test's denied-name extraction (R1773_KEYS) to the deny guard's own denied_env_keys= assignment line, so the new warn block's ascii_upcase | IN(...) line is not swept into the per-key refusal loop (issue gotcha; mirrors deny guard at lib/test/run.sh:32645)
• Write the RED-first behavioral assertions in the The provider env map is exported unfiltered and needs a deny list #1773 block of lib/test/run.sh (extend the existing bash -c harness): watched key warns + exits 0 (one per key), two keys → single warning names both, lower-case matches, longer-name (HOMEDIR) no warning, none-of-four → silence, Bedrock arm with ANTHROPIC_BASE_URL warns, no-env-key entry, non-object .env entry
• Add the warn block to the "Inject provider endpoint" step in all three workflows (byte-identical run body): reuse the deny guard's jq shape reading .env // {} with ascii_upcase | IN("ANTHROPIC_BASE_URL","API_TIMEOUT_MS","HOME","RUNNER_TEMP"), bare command substitution, collect-then-report-once single ::warning::, report-and-continue (no exit); place immediately after the deny guard, before the genv writes (.github/workflows/devflow.yml, devflow-implement.yml, devflow-runner.yml)
• Run the covering suite (monolith shard) and confirm GREEN
• Add a .changeset/*.md file (patch bump) — deferred to Phase 3 per versioning policy (after draft PR exists)
• Documentation (Phase 4.1, deferred): .prflow/config.schema.json, docs/external/docs/configuration/providers.md, docs/internal/cloud-setup.md (incl. the two-notes/three-bullets + schema-carries-none correction), docs/internal/DEVFLOW_SYSTEM_OVERVIEW.md

Acceptance Criteria

• The watched keys are exactly these four — complete by construction: ANTHROPIC_BASE_URL, API_TIMEOUT_MS, HOME, RUNNER_TEMP. When a provider env map names one or more of them, the step prints one ::warning:: naming every key that matched, and exits 0.
• A key the env map sets ends up with the map's value, for the watched keys and every other key alike, unchanged from before this issue: an existing provider configuration produces the same GITHUB_ENV contents it produces today, plus the new warning line.
• Key matching is case-folded and whole-name, the same rule the deny guard directly above already applies: a map naming home warns exactly as one naming HOME does, and a map naming HOMEDIR produces no warning.
• A provider env map naming none of the four watched keys produces no warning, and the step's output is unchanged from before this issue.
• Every name the deny guard refuses today still refuses the run with the same ::error::, and the deny guard's list of names is unchanged.
• The "Inject provider endpoint" step body is byte-identical across the three workflow files after the change, the property the existing three-way body-identity check asserts.
• The test block's per-key refusal loop covers the deny guard's names and none of the four watched keys, so no watched key is asserted to refuse the run.
• A provider entry with no env key at all, and one whose env is not an object, behave exactly as they do today — the new warn block does not introduce a new way for the step to fail.

Devflow Reflection

Devflow Reflection (click to expand)

💡 Improvements

• 💡 The /prflow:implement workpad-invocation ladder resolves to the installed plugin cache, which on a self-hosted PRFlow run can be OLDER than the repository's own scripts/workpad.py. Here the cached v2.34.7 copy rejected --record-completion-evidence-ci / --completion-ci-check (unrecognized arguments), while the in-tree copy — which is what this branch's merged main actually ships — accepts them. The run recovered by invoking scripts/workpad.py directly, but the ladder's rungs name no in-tree copy, so the documented recovery for a version-skewed flag is absent. Concrete improvement: add a rung (or a stated fallback) for the repository's own scripts/workpad.py when the run is executing inside the PRFlow repo itself, or have the ladder report the resolved helper's version so the skew is legible rather than surfacing as an argparse error.
• 💡 lib/test/regenerate-artifacts.py --with-floors returns INFRASTRUCTURE / exit 2 on a macOS desk purely because of a host-capability skip: the create-issue-contract module's #1733 BSD-shaped-ls assertion self-skips (busybox absent), and the floor reconciler then rejects the module with skip-assertion credit met or exceeded the assertion floor 1. The exact-module-floors row is consequently never checked on any host that legitimately self-skips a host-capability assertion, and the batched pass must be recorded skipped every time — on a tree with no drift at all. The floor reconciler counts a host-capability skip against the assertion floor as though it were a missing assertion; those two are different things. Concrete improvement: have the floor reconciliation subtract host-capability skips from the credit it compares against the floor (leaving blocking-gate skips counted as today), so a desk run distinguishes "this host cannot express the condition" from "the module lost an assertion".

ℹ️ Notes

• ℹ️ skill-directory anchor resolved from the runner-reported base directory
• ℹ️ resume-precheck: both open-PR queries ran and returned none for this issue; workpad Branch line absent; no prior attempt to adopt
• ℹ️ park-calibration gate clean: no parked finding matched (shadow re-raised neither the pushed-back Important nor the below-threshold Suggestion; shadow independently confirmed the step runs under set -euo pipefail). over-grade calibration gate clean: no promote-path finding flagged.
• ℹ️ parked-class sweep clean: no new siblings (parked findings are advisory test-hardening nits on lib/test/run.sh; the class-sweep found no new below-threshold siblings; truncation null, dispatch verified). No trackable deferred work: F-1 is a refuted (claim-quality) finding not deferred work, F-2 and the 2 shadow findings are below-threshold advisory nits — deferrals manifest omitted (zero surviving trackable deferrals).
• ℹ️ ## Phase 3.4 AC gate — two-verifier reconciled dispositions (issue Warn when a provider env map sets ANTHROPIC_BASE_URL, API_TIMEOUT_MS, HOME or RUNNER_TEMP #1911) Reconciled via reconcile-ac-verifiers.py: all_satisfied=true, blocking=[], 0 undischarged slots on every criterion. Both the evidence verifier (ran lib/test/run-shard.sh monolith in-env) and the claim verifier (static trace, executes nothing) independently concluded satisfied for all 8, with full per-criterion dispositions. | AC | status | evidence | claim slots | evidence slots | |----|--------|----------|-------------|----------------| | 1 | satisfied | run.sh:32806,32813-32817,32835-32836 warn+exit0 PASS | claim-traced/command-source-read/evidence-recorded = yes | type-decided/command-run=yes, single-flight=no(direct), evidence-recorded=yes | | 2 | satisfied | run.sh:32819,32880 map value still written | all yes | command-run yes, single-flight no(direct) | | 3 | satisfied | run.sh:32824-32831 home warns / HOMEDIR not | all yes | command-run yes | | 4 | satisfied | run.sh:32838-32841 none-of-four silent | all yes | command-run yes | | 5 | satisfied | run.sh:32865-32871 deny unchanged, deny-before-warn | all yes | command-run yes | | 6 | satisfied | R313_BODY_IDENT byte-identity across 3 workflows | all yes | command-run yes | | 7 | satisfied | R1773_KEYS(denied_env_keys=) disjoint from R1911_KEYS(warned_env_keys=); no watched key on deny list | all yes | command-run yes | | 8 | satisfied | run.sh:32850-32863 no-env-key + non-object .env unchanged | all yes | command-run yes | Evidence-verifier note: the monolith shard reported 12 unrelated failures (Keep writer-job push and gh credentials fresh past the App token's 60-minute lifetime #487/Keep writer-job push and gh credentials fresh past the App token's 60-minute lifetime #491/Sign the credential refresher's JWT without openssl process substitution so long cloud runs keep GitHub access on non-Linux runners #1882 credential-refresher liveness / gh-surface-divergence / grep-tail-availability attribution tests) on one run and 0 on another of the same tree — contention-sensitive, pre-existing, and orthogonal to the Warn when a provider env map sets ANTHROPIC_BASE_URL, API_TIMEOUT_MS, HOME or RUNNER_TEMP #1911 inject-step block (every Warn when a provider env map sets ANTHROPIC_BASE_URL, API_TIMEOUT_MS, HOME or RUNNER_TEMP #1911 assertion PASSes on both runs). These do not touch any AC and are tracked separately for the Phase 4.3 whole-suite gate.
• ℹ️ Verification evidence: local/interactive tier — the whole-suite completion gate is the CI reading for the commit this run pushed (CLAUDE.md tier ladder rung 1), so no suite was launched in-environment and the single flight was not consulted (a CI reading is bound to one pushed commit on an external service and is non-reusable by construction). Head read: 653b81db49c7935d6c44eb6c154165a86886feae. Required checks, read by name from the gh pr checks 1919 rollup with the PR head confirmed equal to that SHA both before and after the reading: lib + python tests = pass, lint (shellcheck + actionlint + ruff) = pass. Run URL: https://github.com/The01Geek/prflow/actions/runs/32802043373 (conclusion success; all five shards — monolith, python-pool, modules-large, modules-pin, modules-rest — passed). Recorded as the CI-derived completion-evidence marker via --record-completion-evidence-ci; this run writes no verification-flight marker, so exactly one completion-evidence marker exists across both families.

[prflow-implementer]

DevFlow stall backstop — this cloud run ended while the workpad Status was still in-progress (interim 🚀 Reviewing). Auto-resume attempt 1 of 2:

Resume note: invoke bundled helpers as .prflow/vendor/prflow/scripts/… (and .prflow/vendor/prflow/lib/…) with that path as the leading token — never an absolute path, never repo-root scripts/…, never behind a VAR= prefix or bash <path> wrapper (those forms are silently denied).

Headless note: this is a headless run — ending the turn ends the process, with no re-invocation. Never end the turn while any dispatched agent has not returned; poll to keep the turn alive; treat ScheduleWakeup and any future task-notification as unavailable.

/prflow:implement 1911

[prflow-implementer]

DevFlow stall backstop — this cloud run ended while the workpad Status was still in-progress (interim 🚀 Reviewing). Auto-resume attempt 2 of 2:

Resume note: invoke bundled helpers as .prflow/vendor/prflow/scripts/… (and .prflow/vendor/prflow/lib/…) with that path as the leading token — never an absolute path, never repo-root scripts/…, never behind a VAR= prefix or bash <path> wrapper (those forms are silently denied).

Headless note: this is a headless run — ending the turn ends the process, with no re-invocation. Never end the turn while any dispatched agent has not returned; poll to keep the turn alive; treat ScheduleWakeup and any future task-notification as unavailable.

/prflow:implement 1911

[prflow-implementer]

DevFlow stall backstop — this cloud run ended while the workpad Status was still in-progress (interim 🚀 Reviewing), and the auto-resume cap (max_resume_attempts=2, attempts already made: 2) is exhausted. The job has been failed so the stall is visible; to retry, post a fresh implement trigger comment naming this issue number.

[The01Geek]

/prflow:implement

[prflow-implementer]

DevFlow stall backstop — this cloud run ended while the workpad Status was still in-progress (interim 🚀 Documenting), and the auto-resume cap (max_resume_attempts=2, attempts already made: 2) is exhausted. The job has been failed so the stall is visible; to retry, post a fresh implement trigger comment naming this issue number.