feat(contracts): one-tap ACCEPT/REJECT/FULFILL contract actions (#73)

[Zillatron27]

Summary

The centerpiece of the action-passthrough wave: the contract sheet's deliberately-withheld actions ship, done inside APXM with no switch to APEX per the #25 direction ruling. Your tap is the commit — one tap, one action, nothing unattended. Three commits:

1. refactor(act): extract the action-feedback observer. waitActionFeedback/waitConfirmationResolved/waitActionProgress move from the step machine to lib/act/action-feedback.ts so one implementation serves the ACT engine and one-shot actions. New optional onManualConfirm(pending) callback fires around the manual-confirm window (balanced even on cancel/overlay removal) — the visibility signal the next commit consumes, and the one the future ACT views (#25 Phase D) will reuse. Step-machine behaviour unchanged; existing gate tests pass untouched.

2. feat(shell): manual-confirm visibility mode. Design-phase discovery: with autoConfirm off, APEX's confirmation dialog was un-hidden underneath the opaque APXM shadow host — physically untappable. Now gameState.actConfirmPending hides the shell via CSS (stays mounted), shows a slim ConfirmBar ("Confirm or cancel in APEX below"), and :host(.act-confirm) drops only the host background — never the height, which APEX's layout listeners read as navigation mid-drive (CLAUDE.md gotcha). Base pointer-events: none passes taps through to APEX's dialog. No APXM-side cancel button (deviation from the plan sketch): APEX's own dialog is fully visible/tappable and the observer already handles both exits.

3. feat(contracts): the actions. runContractAction(localId, target): open CONT <localId> off-screen → click APEX's button (case-insensitive text match — visible case is CSS text-transform) → observe feedback → always restore APEX. ACCEPT/REJECT render when acceptance === 'awaiting-mine'; FULFILL per available condition, addressed by ordinal among available conditions (APEX renders one button per fulfillable row; raw indexes would misalign past fulfilled/partner rows). One action in flight at a time; APEX's error text surfaces inline; success needs no refresh (the CONTRACTS_CONTRACT delta updates the store).

Known device-discovery items (#73)

Nobody drives the CONT buffer — not rPrun, not the fork — so these need the dev-build session before release:

• Actual button labels (accept/reject assumed; fulfill candidates: fulfill/pay/provide).
• Whether contract actions pop the confirmation overlay at all (the mechanism handles both).
• ConfirmBar placement vs APEX's dialog (top chosen; swap to bottom if it covers).
• Verify APEX's stack does NOT navigate when act-confirm toggles.

Testing

• 596 tests pass (+16 on this branch): action-feedback signal window semantics (fires/never-fires/balanced-on-cancel), gameState flag, matcher (case-insensitivity, fulfill ordinal, synonyms), runner (success/error/missing-button/confirm-window/in-flight guard/open-failure — buffer always restored).
• Mutation-verified: removing the in-flight guard fails its test; dropping case-folding fails 7.
• npx tsc --noEmit clean; Chrome + Firefox builds green.

Closes #73. Part of #25's direction; the ACT views inherit onManualConfirm + act-confirm + ConfirmBar wholesale.

🤖 Generated with Claude Code

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Updated (UTC)
❌ Deployment failed View logs	apxm	65e62f1	Jul 06 2026, 11:17 AM