[CrysisDeu]

Problem / Motivation

Goal: Fix the flake8 F821 undefined name 'lists_checked_by_caller' that broke Backend Lint on main since 23:05Z.

Two independently-green PRs merged a minute apart left session_denied_reason referencing a name that only existed in publish_denied_reason's parameter list. #24498 moved the body of publish_denied_reason into the new session_denied_reason(session_key, provider_name) function; #24343 added lists_checked_by_caller: bool = False to publish_denied_reason and used it in that body, which now lives in session_denied_reason where the name is not defined.

Why it matters

Every merge to main after 23:05Z inherits the F821, making Backend Lint a permanent red lane until this is fixed. Any PR that runs against the current main tip fails the lint check regardless of what it changes.

Not a goal

• Changing the semantics of lists_checked_by_caller or the deploy-path skip logic introduced by feat(governance): let a policy name publish regions, audience and accounts #24343
• Fixing the pre-existing BLE001 bare-exception catch in session_denied_reason (unrelated, predates both PRs)

What changed (motivation → approach → change)

The F821 at publish_governance.py:299 exists because session_denied_reason uses lists_checked_by_caller in its body but never receives it as a parameter. The fix threads the keyword argument through:

• session_denied_reason gains *, lists_checked_by_caller: bool = False, matching the name and default from feat(governance): let a policy name publish regions, audience and accounts #24343
• publish_denied_reason forwards it: session_denied_reason(..., lists_checked_by_caller=lists_checked_by_caller)
• dispatch_denied_reason (the other caller of session_denied_reason) needs no change — it is not the core deploy path and must always enforce the list check

Backwards compatibility

Compatible: the new parameter is keyword-only with False as default, so every existing caller of session_denied_reason (dispatch_denied_reason, the monkeypatch in test_publish_dispatch_gate.py) continues to work unchanged.

Removes nothing: a parameter is added; no public function is renamed, removed, or has its signature narrowed.

Tests

Two new tests added to test/test_governance_list_publish_targets.py:

• test_session_denied_reason_skips_list_refusal_for_deploy_core_path: calls session_denied_reason directly with lists_checked_by_caller=True; asserts list refusal is skipped for the deploy-web provider
• test_session_denied_reason_enforces_list_refusal_without_flag: calls with the default False; asserts the list refusal is enforced

Proof: not provable -- prove.py reports INCONCLUSIVE (reverted production hunk causes pytest to error at collection rather than at assertion, because the NameError is inside a function body that cannot be collected when the kwarg is absent)

Backend Lint pass on head 7d3be71401: https://github.com/kirodotdev/KiroCrew/actions/runs/40461933154/job/122049169033

Manual verification

N/A — unit coverage sufficient. The defect is a NameError in an auth chokepoint; the fix is mechanical kwarg threading verified by flake8, mypy, and the two new unit tests.

Screenshots / video

N/A — no user-visible frontend change.

Related Issues

Fixes #24764

Sibling sweep

Swept: git grep -n 'lists_checked_by_caller' -- src/

• Sibling: src/kiro_crew/apps/routes_listing.py:290 -- not affected -- calls publish_denied_reason (the public API), not session_denied_reason directly; kwarg is already threaded correctly after this fix
• Sibling: src/kiro_crew/deploy/handlers.py:256,994 -- not affected -- same reason; both call publish_denied_reason with lists_checked_by_caller=True
• Sibling: src/kiro_crew/publish_governance.py:171,181,223,305 -- changed here

Pattern harvest

Rule candidate: review-prompt
Pattern: when extracting a function body into a new helper, every keyword-only parameter used in that body must be added to the helper's signature and forwarded from every caller

Checklist

• At most two commits (one is the norm), with a Conventional Commits title (feat|fix|docs|style|refactor|perf|test|chore|ci|build|revert: ...)
• Existing tests pass and new tests added for new functionality
• Self-review completed; code follows project style guidelines
• Documentation updated (if applicable)
• No secrets, credentials, or internal references in the diff

Contribution License Agreement

[github-actions]

First Principles Review (Opus 5.5) — ✅ PASS

Premise-level review of 7d3be71401149ace56ed65ed21c4e2e3fddf964d — why this exists and whether the shipped surface is the smallest honest version. Updated in place on each push. A BLOCK verdict blocks PR readiness; PASS does not.

First-Principles-Verdict: PASS

Nothing blocks: this restores the behaviour #24343 already pins and fixes a red main lint build (F821).

Notes

• Item 3 — rides along: the existing test_deploy_web_id_skips_the_list_refusal_only_on_the_core_path already asserts both outcomes through publish_denied_reason, which now just forwards the flag. Subtraction: delete test_session_denied_reason_enforces_list_refusal_without_flag and test_session_denied_reason_skips_list_refusal_for_deploy_core_path, or at least the first one.

What this change ships

Inventory (3 items) — 2 justified

Intent: get main's Backend Lint green again so the deploy path's list check works as #24343 meant. FIX.

1. session_denied_reason now takes the lists_checked_by_caller flag, which defaults to off — justified
2. publish_denied_reason hands its flag on, so the core deploy path skips the list refusal again — justified
3. Two direct unit tests for session_denied_reason with the flag on and off — rides along

[FIRST-PRINCIPLES-REVIEWED] 7d3be71

Description read

[DESCRIPTION-READ] 5d8d345d94be20314e30faf6b3e494b0d6564be0e972c242dc7715077ff354e3

That sha256 names the PR description this verdict read. Recompute it with .github/scripts/pr-description-capture.sh; if it differs, the description changed after this verdict was formed and any finding drawn from the description is unproven.

[github-actions]

Design Review (Opus 5.5) — ✅ PASS

Design-level review of 7d3be71401149ace56ed65ed21c4e2e3fddf964d — updated in place on each push. A BLOCK verdict blocks PR readiness; PASS does not.

Design-Verdict: PASS

Nothing blocks. This is a minimal merge-skew repair that restores #24343's intended behaviour on the function where the body now lives. The default stays fail-closed, and the new keyword argument is the only way past the refusal.

[DESIGN-REVIEWED] 7d3be71

Description read

[DESCRIPTION-READ] d2fced65c19028af9ce2ec0de8eee83e3173b0eeb064aac43ef6cbddacdc0e7f

That sha256 names everything this verdict read: the PR description, plus the 1 evidence file(s) the workflow collected from it and handed this review. It covers that evidence because the media strip replaces every attachment URL with the same placeholder, so an edit swapping one attachment for another would leave the description's captured text identical while what this review judged changed. Recompute it with .github/scripts/pr-description-capture.sh over the same inputs; if it differs, the description or that evidence changed after this verdict was formed and any finding drawn from either is unproven.

[github-actions]

UX Review (Opus 5.5) — ⏭️ skipped

Revision 7d3be71401149ace56ed65ed21c4e2e3fddf964d touches no user-facing surface (no changes under website/ or committed screenshots), so the UX review was skipped. Does not block merge.

[github-actions]

Opus 5.5 Review — ✅ no blocking findings

Reviewed 7d3be71401149ace56ed65ed21c4e2e3fddf964d — this comment is updated in place on each push.

Review details

No findings.

[OPUS-REVIEWED] 7d3be71

Verdict parsed from the review's SHA-scoped output markers for commit 7d3be71401149ace56ed65ed21c4e2e3fddf964d.

False positive or not applicable? A repository writer can comment:
/ai-review override fable 7d3be71401149ace56ed65ed21c4e2e3fddf964d false-positive: <reason, 20 to 500 characters>

[github-actions]

GPT 6.1 Review — ✅ no blocking findings

GPT 6.1 completed its review of 7d3be71401149ace56ed65ed21c4e2e3fddf964d and found no blocking issues.

This comment is updated in place on each push.

Review details

No findings.
[GPT-REVIEWED] 7d3be71

False positive or not applicable? A repository writer can comment:
/ai-review override gpt 7d3be71401149ace56ed65ed21c4e2e3fddf964d false-positive: <reason, 20 to 500 characters>

[buluoray]

Approving 7d3be71. This fixes main: #24343 and #24498 merged a minute apart, and together they leave session_denied_reason reading lists_checked_by_caller (publish_governance.py:299 on main) without having it as a parameter, so flake8 fails with F821 and the deploy-list check raises NameError at runtime. The PR adds it as a keyword-only parameter defaulting to False and passes it through from publish_denied_reason only. dispatch_denied_reason keeps the default, so the dispatch path still enforces the list refusal (fail closed), and only the core deploy path can skip it. The two new tests pin both sides. Locally at this head flake8 -select=F is clean on the file and the governance publish tests run 284 passed.

PR Hygiene is red on the description sections; rebuilding the body from .github/PULL_REQUEST_TEMPLATE.md clears it without a push.