NAI Analysis — the one that isn't a slash command

The agent systems in this workspace are all the same shape: type a command, an orchestrator dispatches subagents in waves, you get a file to check. nai-analysis is something else — a private, always-on web app — extracted to its own repository, github.com/udopnink/nai-analysis, on 2026-07-29, so it no longer lives inside this one — where Udo tracks architecture, MBSE, and tool-integration issues, each one either a decision (options on the table, one eventually picked) or a discussion (analysis with no forced choice). A specific client contact can be invited, via Google sign-in, to view and comment on one specific issue — never anything broader — and two narrower no-login paths exist alongside that invite: a hard-to-guess read-only share link, and a public showcase card that carries a teaser, never the full body.

It was built with GSD’s phase-based discuss→plan→execute→verify loop rather than this workspace’s own orchestrator/subagent/tool convention, because the thing being built is a persistent product with a database and a deploy pipeline, not a one-shot dispatch that produces a document. Same underlying discipline — explicit plans, a verify step before anything is called done — applied to a different kind of artifact.

What an issue is

The access model

The screens

Working an issue

The dashboard

Sharing, revoking, and the showcase

How it's built

%%{init: {'theme':'neutral', 'flowchart':{'htmlLabels':false,'nodeSpacing':45,'rankSpacing':55}}}%%
flowchart TD
    U["Owner or invited client<br/>signed in with Google"] --> P
    A["Anyone holding a share link<br/>or reading the showcase"] --> NOLOGIN

    subgraph L1 ["proxy.ts - runs on every matched request"]
        P["Refreshes the Supabase<br/>session cookie"]
    end

    P --> PUB["(public) sign-in page"]
    P --> APP["(app) route group<br/>layout.tsx gates on getClaims()"]

    APP --> ACT["Server Actions<br/>issues/actions.ts"]
    NOLOGIN["showcase / and share link /s/:token<br/>no session at all"]

    subgraph L2 ["Supabase - the sole enforcement point"]
        ANON["SECURITY DEFINER, anon-callable<br/>get_shared_issue,<br/>get_showcase_issues"]
        RPC["SECURITY DEFINER RPCs<br/>create_issue_with_options,<br/>pick_decision_option,<br/>claim_pending_invite"]
        RLS["Direct table writes<br/>gated by RLS policy"]
        DB[("issues · issue_options<br/>issue_invites · issue_comments")]
    end

    ACT --> RPC
    ACT --> RLS
    NOLOGIN --> ANON
    RPC --> DB
    RLS --> DB
    ANON --> DB

    classDef orch fill:#dcefe9,stroke:#0f6f63,stroke-width:2px
    classDef tool fill:#f4f1ea,stroke:#8a7a5a
    classDef human fill:#fdf3e0,stroke:#8a5a00,stroke-width:2px
    class U,A human
    class P,NOLOGIN orch
    class RPC,RLS,ANON,DB tool

The boundary rule is the same species as the one on the why the promise holds page, just enforced by a different mechanism: there, a guarantee is a tool grant a subagent literally cannot exceed; here, it's a database policy the Next.js layer cannot route around even with a bug, because no Server Action performs its own ownership check — a rejected RLS write (0 rows affected) or a failing RPC is the authorization outcome, not a belt-and-suspenders backup to one.

The seam to this workspace

The one seam between the two worlds is /nai-issue-to-agent: it fetches one nai-analysis issue, feeds it to /nai-option-study or /nai-review, and posts the finished write-up back onto the issue as a comment — after a STOP for explicit confirmation, since a posted comment can't be deleted through that path. That's the only place an agent system and this app talk to each other; everything else about nai-analysis runs on its own, independent of the systems in this workspace.

Known limitations