Documents four persistent operational findings from the 2026-05-11
Gitea migration and CI noise investigation:
1. Runner network isolation (git remote unreachable from container)
2. continue-on-error only works at step level, not job level
3. workflow_dispatch.inputs not supported
4. fetch-depth:0 on actions/checkout times out
References PR #441 (harness-replays detect-changes fix) and
Task #173 (pre-clone manifest deps pattern).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Cherry-picked from PR #452 (fix/canvas-test-and-design-fixes) which
was closed without merge during the PR #443 cascade. The fix adds a
mockPost reference so individual tests can reset the POST mock cleanly
instead of queueing multiple resolved/rejected values.
Without this, the "shows an error toast when POST fails" and "keeps
the card visible when POST fails" tests queue two responses from
beforeEach's mockResolvedValue({}) and the second mockRejectedValueOnce()
call, causing non-deterministic test outcomes.
Fixes test failures in ApprovalBanner suite.
Re-applies PR#462 on current main (PR#443 merged first and renamed
canary-staging.yml -> staging-smoke.yml, conflicting #462).
Swept 6 files (15 secret-ref flips):
- .gitea/workflows/staging-smoke.yml (3 refs + drop continue-on-error + add notify-on-failure step)
- .gitea/workflows/e2e-staging-saas.yml (3 refs)
- .gitea/workflows/e2e-staging-sanity.yml (3 refs)
- .gitea/workflows/e2e-staging-canvas.yml (3 refs)
- .gitea/workflows/e2e-staging-external.yml (3 refs)
- tests/e2e/STAGING_SAAS_E2E.md (1 heading flip + 1 historical-rename breadcrumb)
Each workflow keeps one inline breadcrumb comment pointing back to
the old name and internal#322.
staging-smoke is the 30-min canary cadence for the entire staging
SaaS stack; silent failure (continue-on-error: true) masked exactly
the regressions the smoke exists to surface, same class as PR#461
(`sweep-stale-e2e-orgs`). Dropped continue-on-error from the smoke
job + added a fail-loud `if: failure()` Notify step mirroring
PR#461. The four other `e2e-staging-*` workflows KEEP
continue-on-error: true per RFC #219 §1 — they are advisory.
Excluded from this PR:
- .gitea/workflows/sweep-stale-e2e-orgs.yml (PR#461 owns)
- .gitea/workflows/staging-verify.yml (only references the plural MOLECULE_STAGING_ADMIN_TOKENS canary-fleet secret, out of scope)
- scripts/staging-smoke.sh (same — plural only)
- docs/architecture/canary-release.md (same — plural only)
- .github/ mirror tree (separate scope per reference_molecule_core_actions_gitea_only)
Verified locally: yaml.safe_load clean on all 5 workflows; grep
returns ZERO non-breadcrumb references in the swept files; the
plural MOLECULE_STAGING_ADMIN_TOKENS references in
staging-verify.yml / scripts/staging-smoke.sh / canary-release.md
are intentionally untouched.
Refs: internal#322, PR#461, feedback_rename_pr_and_edit_pr_conflict_sequence
Gitea Actions runners cannot reach https://git.moleculesai.app over HTTPS
(runbooks/gitea-operational-quirks.md §runner-network-isolation).
fetch-depth: 0 on actions/checkout triggers a full repo history fetch
that times out at ~15s, causing the workflow to fail on Gitea runners
(main RED, issue #460).
Fix: use fetch-depth: 1 (shallow clone) and explicitly fetch tags with
git fetch origin --tags --depth=1. The collision check (git tag --list)
still works since we only need the most recent tag, not full history.
git push of the new tag works on a shallow clone.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Follows up on #432 (merged). Extracts _check_delegation_results_pending()
from the inline guard in _run_idle_loop() so tests can call the real
production function directly via patch(builtins.open, ...).
Fixes#401: the previous test used a mirror copy of the guard logic,
which risks drifting from the production implementation over time.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
PurchaseSuccessModal tests used a fixed 50ms setTimeout to wait for the
dialog to appear after React useEffect batch + createPortal. This was
flaky because React's rendering timing varies.
Replace waitForDialog() fixed-delay with waitFor() polling — the test
waits exactly as long as React needs, no more. Update all dismiss tests
to use act(() => setTimeout(...)) after vi.useRealTimers() for reliable
real-timer behavior.
Result: 18/18 tests pass (was 14/18 with 4 timing-related failures).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Gitea Actions quirk: continue-on-error: true only works at the step level,
not the job level (opposite of what the docs imply). Without step-level
continue-on-error, the detect-changes job was reporting status=failure
despite job-level continue-on-error: true.
Two-part fix:
1. continue-on-error: true on both the fetch and decide steps — belt-and-
suspenders against any remaining exit code leaks.
2. || true on DIFF=$(git diff ...) — git diff exits 1 when BASE is not
in local history (shallow checkout / unfetched commit). With
set -euo pipefail, that made the decide step itself fail. The empty
diff from the || true means "no changes" → run=false is correct;
the harness runs unconditionally when the fetch times out anyway.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Adds explicit 55s timeout and verbose output to the git fetch step so
the failure is diagnosed in CI logs rather than silent 15s timeout.
55s is well within the 60-min job timeout; enough for cold TCP handshake
+ one git pack transfer on a local network.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
git fetch origin <sha>:<sha> is not valid syntax for fetching an arbitrary
commit (git needs a ref to locate the commit on the remote). Switch to
git fetch origin main --depth=1 which fetches the main branch tip + its
immediate parent. The base commit is the parent of the PR head on main,
so depth=1 is sufficient.
github.event.pull_request.base.ref = "main" (confirmed from API) — this
is the branch name, not the SHA. git fetch origin main --depth=1 fetches
the branch tip and one ancestor, giving us the base commit in a single cheap
network call.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
## Why
Gitea 1.22.6's `pull_request_review` event doesn't refire workflows
(go-gitea/gitea#33700). The existing sop-tier-check workflow subscribes
to the review event, but the subscription is silently dead. When an
approving review lands AFTER tier-check ran on PR-open/synchronize, the
PR's `sop-tier-check / tier-check (pull_request)` status stays at
failure forever, forcing the orchestrator down the admin force-merge
path (audited via audit-force-merge.yml, but the audit trail keeps
growing — see feedback_never_admin_merge_bypass).
## What
New `.gitea/workflows/sop-tier-refire.yml` listening on `issue_comment`
events. When a repo MEMBER/OWNER/COLLABORATOR comments
`/refire-tier-check` on a PR, the workflow re-invokes the canonical
sop-tier-check.sh and POSTs the resulting status directly to the PR
head SHA (no empty commit, no git history bloat, no cascade re-fire of
every other workflow).
## Security model
Three gates in the workflow `if:` expression — all required:
1. `github.event.issue.pull_request != null` — comment is on a PR, not
a plain issue.
2. `author_association` ∈ {MEMBER, OWNER, COLLABORATOR} — only repo
collaborators+ can flip the status (per the internal#292 core-security
review#1066 ask).
3. Comment body contains `/refire-tier-check` — slash-command-shaped,
not just any word in normal review prose.
Workflow does NOT check out PR HEAD; only HTTP-calls the Gitea API.
Same trust boundary as sop-tier-check.yml's `pull_request_target`.
## DRY: re-uses sop-tier-check.sh
Refire shells out to the canonical script with the same env the original
workflow provides. We get the EXACT AND-composition gate, not a
watered-down approving-count check.
## Rate-limit
30-second window between status updates per PR head SHA — prevents
comment-spam status thrash. Override via SOP_REFIRE_RATE_LIMIT_SEC or
disable for tests via SOP_REFIRE_DISABLE_RATE_LIMIT=1.
## Tests
`.gitea/scripts/tests/test_sop_tier_refire.sh` — 23 assertions across
T1-T7 covering: success POST, failure POST, no-op on closed, rate-limit
skip, plus YAML-level checks of all three security gates. Real script
runs against a local-fixture HTTP server (`_refire_fixture.py`) with a
mock tier-check (`_mock_tier_check.sh`) — the latter sidesteps the
known bash 3.2 (macOS dev) parser bug on `declare -A`; Linux Gitea
runners (bash 4/5) use the real sop-tier-check.sh in production.
Hostile self-review verified:
- Tests FAIL on absent code (exit 1, FAIL=2 PASS=0 in existence-block).
- Tests FAIL on swapped success/failure label (exit 1).
- Tests PASS on correct code (exit 0, 23/23).
## Brief-falsification log
(a) Keep using force_merge — no, this is the issue being closed.
(b) Empty-commit re-trigger — no, status-POST is cleaner + faster +
doesn't bloat git history.
(c) author_association check in the script not the workflow — both work
but workflow-level short-circuits faster (saves runner spin).
(d) Re-implement a watered-down tier-check inside refire — no, that's a
security regression (skips team-membership AND-composition).
Refire shells out to the canonical script.
Tier: tier:high (unblocks approved-PR-backlog drain class).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Previous attempt used fetch-depth:0 on actions/checkout, but the 75 MB
repo full-history fetch times out on the operator-host runner network
(github.com unreachable, apt mirrors ~3s timeout). A full history fetch
also takes >1m18s even when it doesn't fail.
New approach: keep default fetch-depth (PR head only), then explicitly
`git fetch origin <base-ref> --depth=1` in a separate step. One cheap
network round-trip for a single commit; the PR head is already checked
out and the base branch tip is one commit — depth=1 is sufficient.
Spotted during gate triage review (core-lead-agent, 2026-05-11).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Co-authored-by: Molecule AI Infra-Runtime-BE <infra-runtime-be@agents.moleculesai.app>
Co-committed-by: Molecule AI Infra-Runtime-BE <infra-runtime-be@agents.moleculesai.app>
The detect-changes step runs `git diff "$base_sha" "$head_sha"` but the
preceding `actions/checkout` uses the default fetch-depth: 1 — only the
PR head commit is fetched. The base ref (github.event.pull_request.base.sha)
is not in the local history, so git diff fails silently (2>/dev/null),
leaving DIFF empty and the step exits non-zero. With continue-on-error: true
on the job, the step reports "failure" instead of blocking the PR, but the
output is never written so downstream harness-replays always skips.
Fix: add fetch-depth: 0 to the detect-changes checkout step so full history
is fetched and both base and head refs exist locally.
Spotted during gate triage review (core-lead-agent, 2026-05-11).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Promotes the complete OFFSEC-003 boundary-marker sanitization from staging
to main, including:
- _delegate_sync_via_polling: sanitize response_preview and error strings
before returning (OFFSEC-003 polling-path fix from PR #417).
- tool_check_task_status JSON endpoint: sanitize summary + response_preview
in both the task_id filter path and the list path.
- tool_delegate_task non-polling path: preserve main's existing
sanitize_a2a_result(result) wrapper (staging accidentally removed it).
Closes#418.
Co-Authored-By: Molecule AI · core-be <core-be@agents.moleculesai.app>
