[eyeveil]

Why

The fork has no push delivery path: no relay and no Firebase or APNs project. The user decided not to build one. Without delivery, the lock-screen Allow once and Decline actions from #107 can never fire, so this removes them.

What changed

• Reverts feat: answer agent approvals from mobile notification actions #107 (cf994a16803) in full: the mobile notification actions, the HTTP respond endpoint, UserCommandDispatch, the relay payload fields, the expo-notifications patch change, and its docs.

Scope

• Nothing merged after feat: answer agent approvals from mobile notification actions #107, and feat(web): watched pull requests show their checks under the sidebar row #105, feat: pinned decisions panel for open choices across environments #106 and feat(web): Fleet board for Home's chiefs of staff #108 don't use its code. The resulting tree is identical to 5d6f358859 (feat(web): Fleet board for Home's chiefs of staff #108's merge), whose PR head passed all 31 checks.
• No upstream relay or push code is touched beyond what feat: answer agent approvals from mobile notification actions #107 added.

Verification

• git rev-parse HEAD^{tree} equals 5d6f358859^{tree} (3d644cc0f5).

Model and harness: Claude Opus 5.5 (revert) via Claude Code in T3 Code.

---

^{Open in [code]smith · Need help on this PR? Tag @codesmith-bot with what you need.}

[greptile-apps]

Confidence Score: 5/5

[Medium impact] The revert appears safe to merge.

Summary

Reverts lock-screen approval actions and their supporting HTTP, mobile, and relay code.

• Mobile approval choices stay on the thread instead of alerts.
• Push messages carry activity details without approval-answer data.
• Mobile approval answers no longer travel through a runtime-request HTTP route.

eyeveil explicitly states that removing approval actions and their supporting delivery behavior is intentional because the fork has no push delivery path.

_{Reviews (1) · Last reviewed commit: "Revert lock-screen approval actions (#10..." · Reviewed by Greptile}