[APP-2] Second reference application (NaaP Sample CLI) — DO NOT MERGE

[seanhanca]

🚫 DO NOT MERGE — Phase-2 generalization artifact. Based on preview/phase-2-integration, not main.

Coordination

Plan PR ID:   APP-2
Repo:         NaaP (livepeer/naap)
Base:         preview/phase-2-integration
Depends-on:   NAAP-D, NAAP-B (+ NAAP-C front door, NAAP-1 seats)
Blocks:       INT-G
Feature flag: key_validation_front_door + app_registry (default OFF)
Merge-safety: a new standalone example app + tests only; touches no runtime route;
              does nothing unless the front-door/app_registry flags are ON. INV-1 green.

What

A minimal second reference application (examples/app2-cli) that uses a native naap_ key through the NAAP-C front door (BPP ③) to run an inference job. Shares zero code with Storyboard; provider-agnostic (never sees a provider token/URL — only an opaque signerSession + gated capabilities). Proves the API key + capability model is app-agnostic (generalization E9).

• examples/app2-cli/ — zero-dependency ESM front-door client + runnable CLI + app2.descriptor.json (NAAP-D registration) + README. Structured JSON logs only; key always redacted; node --test suite (9 tests, green).
• apps/web-next/.../app2-attribution.test.ts — drives the real front door with the SAME key under two registered apps (Storyboard + APP-2): asserts distinct per-app attribution; capabilities gated to each app's grant (text-to-video filtered for APP-2); same flow works under the stub provider (E8).

Self-review

• App-agnostic: no Storyboard imports; only coupling is the front-door contract + X-App-Id.
• Provider-agnostic: identical under pymthouse vs stub (tested).
• Safe: needs key_validation_front_door (+ app_registry) ON to act; default OFF ⇒ no prod impact. No secrets.

DoD

• Second app registered via NAAP-D; uses a naap_ key through the front door
• Usage attributes to APP-2's appId, distinct from Storyboard
• Provider-agnostic (works under stub) — E8/E9
• No prod impact (flags default OFF) — INV-1 green
• DO NOT MERGE (intentional)

Made with Cursor

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
naap-platform	Ready	Preview	Jun 17, 2026 9:37pm

[github-actions]

⚠️ This PR is very large (512 lines changed). Please split it into smaller, focused PRs if possible.

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: c85d648e-3cac-4ce0-bf98-61d1a47f2da8

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/app-2-second-app

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[seanhanca]

🔎 Self code-review (APP-2)

Correctness

• buildValidateRequest enforces D1 (native naap_ only) and requires X-App-Id, so attribution can't silently drop. Envelope parsing tolerates both {success,data} and a bare payload.
• The in-suite app2-attribution.test.ts exercises the real front-door handler (not a reimplementation), so the attribution + capability-gating assertions reflect production behavior.

App- & provider-agnosticism (the point of APP-2)

• No Storyboard imports anywhere in examples/app2-cli. The only NaaP coupling is the documented front-door contract.
• The signer session is forwarded opaquely (headers verbatim, or accessToken→bearer); the app never interprets provider internals → works identically under pymthouse and stub (covered by the E8 test).

Safety

• Does nothing unless key_validation_front_door (+ app_registry) are ON ⇒ no prod impact (INV-1).
• Structured JSON logs only; key always redacted (naap_…WXYZ). No fallback path that could mask failures — an independent app should just report.

Risks considered

• Tests under examples/ use node --test (zero-dep) so they're runnable standalone; the CI-relevant assertions also live in the web-next vitest suite to guarantee they run.