format nova reports so they aren't wall of text and brain spraining

Agent reports are currently too log-like. Useful details get buried: context, risk, actions taken, final state, and follow-up. Please add a structured completion format for git/project work: - Context - Risk - Resolution - Result - Follow-up - Proposed convention Reference mockup: https://imgur.com/a/kx2uHGB This would make reports easier to convert into issues, PR notes, changelog entries, and audit trails. Why it matters For shared-checkout / multi-agent work, maintainers need to quickly see: - what changed - where it landed - whether the main checkout stayed clean - whether signing was verified - what follow-up is needed Category UX improvement / agent workflow reporting / warlock readability

iOS Error

That confirms the iOS app needed the daemon endpoint origin fix, not more Tailscale work. I’ll leave the current setup as-is: - Tailscale Serve -> tokenless mobile server on 127.0.0.1:3000 - Cave daemon running - ts.net origin allowed for daemon API calls 2. That makes sense. Safari likely primed the Tailscale/cert/session path, then the app’s requests started resolving cleanly. Net result: desktop config is fixed and the phone can connect. 3. Yes. This is a real bug. What likely happened: - The app could reach the desktop, but daemon startup/status was stuck behind the bad forbidden origin path. - After I patched the origin rule, Safari was the first client to successfully hit the web UI/API over https:/...ts.net. - That request triggered or cleared the daemon bootstrap path. - Once the daemon was running/recognized, the native app worked. So Safari didn’t fix Tailscale. It accidentally completed a first-run bootstrap step the iOS app should have completed itself, or at least retried cleanly. Bug shape: CovenCave iOS native connect can remain failed until the same desktop URL is opened in Safari once. Expected behavior: native app should perform the same bootstrap/daemon status/start flow, or show a precise actionable error.

OpenClaw integration

I hit several OpenCoven :left_right_arrow: OpenClaw integration issues while getting Coven Cave connected: > 1. Coven Cave 0.0.112 invoked openclaw agent with --session-key, but OpenClaw 2026.5.3-1 expects --session-id. This produced: unknown option '--session-key' > 2. The default familiar was configured as openclaw_agent = "default", but my OpenClaw default agent ID is actually main. Error: Unknown agent id "default" > 3. When OpenClaw needed a scope upgrade, Coven surfaced this poorly as: _The "openclaw" agent bridge returned no text._ The real issue was a pending OpenClaw device approval for operator.write. 2. > 4. Relaunching Coven Cave left multiple stale server.mjs sidecar processes running, so fixes didn’t apply until I manually killed the old sidecars. > Suggested fixes: - Detect OpenClaw CLI version/capabilities and use --session-id vs older flags appropriately. - Resolve the default OpenClaw agent via openclaw agents list --json instead of assuming default. - Surface pairing/scope approval errors explicitly in the UI. - Ensure app relaunch kills stale bundled sidecar processes. - Parse OpenClaw JSON robustly or separate stderr/stdout so gateway notices don’t become “no text.”

I would like support of the Anti-Gravity CLA, aka Gemini CLI, as well.