Design spec: idea-completion determination + customer-facing status for APR (no GitHub UI exposure)

[JSONbored]

Problem

An idea-submitter using APR never sees a GitHub PR, issue, or commit — so ORB's existing review/merge signals (which assume someone is watching GitHub) can't be the completion signal. No spec exists for who or what decides "this idea is done," or how that gets communicated.

Area

Product spec / UX / platform.

Proposal

Define: what marks an idea complete (a task-graph's own acceptance criteria being satisfied and merged, per #4779's schema? A milestone threshold?), and what the idea-submitter actually sees when it happens, given they have no GitHub-facing surface at all — a dashboard notification, an email, something else. Worth being explicit that "ORB decided it's done" and "the customer has a working thing they can use" aren't automatically the same claim.

Deliverables

• A written spec covering: the completion trigger and the customer-facing notification surface.

Acceptance criteria

• Spec states the completion trigger and notification surface explicitly.

Resources

• Idea-intake bridge schema #4779 (idea-intake schema — completion likely ties to its acceptance-criteria representation)
• Launch-readiness gate #4810 (launch-readiness gate — same "verify against reality, not a mock" discipline applies here)
• The APR hosting/ownership spec (sibling issue, same epic)

Boundaries

No reward/pricing figures. Spec-level only.

maintainer-only — product/UX decision, not a build task.

---

Addendum (2026-07-20): revised per maintainer direction — this should not default to mandating human confirmation. It should reuse the existing per-repo autonomy dial exactly as self-hosted ORB already works: observe / auto_with_approval / auto, per action class, deny-by-default (AUTONOMY_LEVELS, packages/loopover-engine/src/settings/autonomy.ts:7), configurable rather than hardcoded to one policy. For APR specifically, that dial needs a loopover-dashboard surface to configure it, since an APR customer has no .loopover.yml/GitHub-settings access the way a BYOR customer does — the dial's default should still be the same observe deny-by-default floor as everywhere else in the system until a customer (or loopover, as the default operator) explicitly raises it.

The closely related question of what an APR project's autonomy/quality-gate threshold should start at, given it has no operator to set one manually, is tracked separately — see the new cold-start/indexing-period design issue, since it's really about the existing tightening-only self-tune loop (src/settings/repository-settings.ts:20-30) having nothing to tighten from on a brand-new project, not specific to this issue's completion-signal question.

[linear-code]

JSO-5377

[JSONbored]

Research finding worth folding into "what counts as done" (2026-07-21): competitive research on comparable AI-app-builder platforms found that their real-world incidents almost entirely trace to the generated app's own data/auth model, not their sandbox/infra isolation — Lovable's CVE-2025-48757 (missing/misconfigured Supabase Row-Level-Security policies across ~170 generated apps, exposing PII) and a well-documented pattern of hardcoded API keys shipped in Bolt.new-generated client bundles. For APR specifically, loopover's own agent is in the same position those platforms' agents are — producing a new app's data/auth layer from scratch with no human necessarily reviewing it before the customer sees it "done."

Worth an explicit call on whether this issue's completion criteria should include a basic data/auth-safety sanity check (e.g. an RLS-equivalent-exists check, no obviously-exposed secrets in generated client code) before something is communicated to the customer as finished — not just "does it run / do the tests pass." Not resolving it here, just flagging it as a real category of risk this issue's scope should account for, based on where comparable platforms actually got burned.