loki-mode 11.3.0 → 11.3.2

package/docs/DASHBOARD_V2_CHECKLIST.md

@@ -1,243 +0,0 @@
-# Loki Mode Dashboard V2 - Implementation Checklist
-
-> **Historical:** this describes the classic dashboard, removed in Loki Mode 10.8. The Control Plane is the only UI; see [control-plane-migration.md](control-plane-migration.md).
-
-## Overview
-Enterprise-grade Kanban dashboard with FastAPI backend, cross-project support, and CLI integration.
-
-**Target Version:** v6.0.0
-**Status:** Planning Complete
-
----
-
-## Phase 1: Backend Foundation
-
-### 1.1 FastAPI Server Setup
-- [ ] Create `dashboard/server.py` with FastAPI app
-- [ ] Add SQLite database with SQLAlchemy models
-- [ ] Implement health check endpoint `/health`
-- [ ] Add CORS middleware for frontend
-- [ ] Create Dockerfile for dashboard
-
-### 1.2 Database Models
-- [ ] Project model (id, name, path, alias, status)
-- [ ] Session model (id, project_id, status, started_at)
-- [ ] Task model (id, title, status, priority, type, project_id)
-- [ ] Agent model (id, session_id, type, model, status)
-- [ ] Log model (id, session_id, level, message, timestamp)
-
-### 1.3 Core API Endpoints
-- [ ] GET/POST `/api/projects` - Project management
-- [ ] GET/POST/PUT/DELETE `/api/tasks` - Task CRUD
-- [ ] POST `/api/tasks/{id}/move` - Move task between columns
-- [ ] GET `/api/status` - System status
-- [ ] GET `/api/agents` - Active agents
-
-### 1.4 WebSocket/SSE
-- [ ] WebSocket endpoint `/ws` for real-time updates
-- [ ] Event types: task:*, session:*, agent:*, log:*
-- [ ] Heartbeat mechanism
-- [ ] Reconnection handling
-
----
-
-## Phase 2: CLI Integration
-
-### 2.1 Dashboard Commands
-- [ ] `loki dashboard start [--port] [--host]`
-- [ ] `loki dashboard stop`
-- [ ] `loki dashboard status`
-- [ ] `loki dashboard url [--format json|text]`
-- [ ] `loki dashboard open`
-
-### 2.2 Project Commands
-- [ ] `loki projects list`
-- [ ] `loki projects add [path] [--alias]`
-- [ ] `loki projects remove [alias|path]`
-- [ ] `loki projects select`
-
-### 2.3 State Synchronization
-- [ ] Update run.sh to notify dashboard on events
-- [ ] Implement dashboard-state.json writer
-- [ ] Add file watcher for .loki/ changes
-- [ ] Bidirectional task sync
-
----
-
-## Phase 3: Frontend (React + Vite)
-
-### 3.1 Project Setup
-- [ ] Initialize Vite + React + TypeScript
-- [ ] Add TailwindCSS with Anthropic design tokens
-- [ ] Configure build for embedding in Python package
-- [ ] Add Zustand for state management
-
-### 3.2 Layout Components
-- [ ] Sidebar navigation (260px desktop, off-canvas mobile)
-- [ ] Top header with status bar
-- [ ] Project selector dropdown
-- [ ] Theme toggle (light/dark)
-
-### 3.3 Kanban Board
-- [ ] 5 columns: Backlog, Pending, In Progress, Review, Done
-- [ ] Drag-and-drop with @dnd-kit
-- [ ] Task cards with priority badges
-- [ ] Column WIP limits
-- [ ] Filter and sort controls
-
-### 3.4 Task Management
-- [ ] Task detail modal
-- [ ] New task form
-- [ ] Edit task inline
-- [ ] Delete with confirmation
-- [ ] GitHub issue import
-
-### 3.5 Control Panel
-- [ ] Start/Stop/Pause/Resume buttons
-- [ ] Status indicators (mode, phase, RARV step)
-- [ ] Quality gates display
-- [ ] Memory system bars
-
-### 3.6 Additional Views
-- [ ] Agents monitor grid
-- [ ] Log viewer (terminal style)
-- [ ] Memory/Learnings browser
-- [ ] Settings page
-
----
-
-## Phase 4: Session Control
-
-### 4.1 Control Endpoints
-- [ ] POST `/api/control/start` - Start Loki Mode
-- [ ] POST `/api/control/stop` - Stop execution
-- [ ] POST `/api/control/pause` - Pause execution
-- [ ] POST `/api/control/resume` - Resume execution
-- [ ] POST `/api/control/input` - Inject human input
-
-### 4.2 Process Management
-- [ ] Spawn run.sh from dashboard
-- [ ] Track PID and monitor process
-- [ ] Handle graceful shutdown
-- [ ] Support background mode
-
----
-
-## Phase 5: Cross-Project Features
-
-### 5.1 Project Registry
-- [ ] Store projects in ~/.loki/dashboard/projects.json
-- [ ] Auto-discover .loki directories
-- [ ] Project health monitoring
-- [ ] Last accessed tracking
-
-### 5.2 Unified Views
-- [ ] Cross-project task list
-- [ ] Combined activity feed
-- [ ] Aggregated metrics
-- [ ] Global search
-
-### 5.3 Memory Integration
-- [ ] Display cross-project learnings
-- [ ] Search patterns/mistakes/successes
-- [ ] Export learnings
-- [ ] Learning statistics by project
-
----
-
-## Phase 6: Enterprise Features
-
-### 6.1 Authentication
-- [ ] Token-based auth for remote access
-- [ ] `loki dashboard token generate/revoke/list`
-- [ ] Bearer token validation middleware
-- [ ] Optional OIDC/SAML support
-
-### 6.2 Audit & Logging
-- [ ] Audit trail in audit.jsonl
-- [ ] Action logging (start, stop, task changes)
-- [ ] User attribution
-- [ ] Log retention policy
-
-### 6.3 Deployment
-- [ ] Docker Compose with PostgreSQL
-- [ ] Environment variable configuration
-- [ ] TLS/HTTPS support
-- [ ] Reverse proxy compatibility
-
----
-
-## Phase 7: Testing & Documentation
-
-### 7.1 Backend Tests
-- [ ] Unit tests for API endpoints
-- [ ] Integration tests for WebSocket
-- [ ] Database migration tests
-- [ ] Authentication tests
-
-### 7.2 Frontend Tests
-- [ ] Component tests with Vitest
-- [ ] E2E tests with Playwright
-- [ ] Accessibility tests
-- [ ] Mobile responsive tests
-
-### 7.3 CLI Tests
-- [ ] Command parsing tests
-- [ ] Integration with dashboard server
-- [ ] Error handling tests
-
-### 7.4 Documentation
-- [ ] API documentation (OpenAPI/Swagger)
-- [ ] CLI command reference
-- [ ] Deployment guide
-- [ ] User guide with screenshots
-
----
-
-## Dependencies
-
-### Backend
-- Python 3.11+
-- FastAPI
-- SQLAlchemy 2.0
-- Uvicorn
-- Pydantic
-
-### Frontend
-- React 18
-- Vite
-- TailwindCSS
-- @dnd-kit (drag-and-drop)
-- Zustand (state)
-- Lucide React (icons)
-
-### Build
-- Docker
-- Node.js 18+ (for frontend build)
-
----
-
-## Success Metrics
-
-- [ ] Dashboard loads in < 2 seconds
-- [ ] WebSocket updates in < 100ms
-- [ ] Support 10+ concurrent projects
-- [ ] Mobile-friendly (responsive)
-- [ ] WCAG AA accessibility
-- [ ] Zero npm dependencies in backend
-
----
-
-## Timeline
-
-| Phase | Duration | Status |
-|-------|----------|--------|
-| Phase 1: Backend | 1 week | Not Started |
-| Phase 2: CLI | 3 days | Not Started |
-| Phase 3: Frontend | 2 weeks | Not Started |
-| Phase 4: Session Control | 3 days | Not Started |
-| Phase 5: Cross-Project | 1 week | Not Started |
-| Phase 6: Enterprise | 1 week | Not Started |
-| Phase 7: Testing | 1 week | Not Started |
-
-**Total: ~6 weeks**

package/docs/DEMOS.md

@@ -1,63 +0,0 @@
-# Loki Mode -- Interactive Content Index
-
-Complete listing of all interactive HTML experiences in the Loki Mode repository. 8 files total across three categories.
-
-## Overview (1 HTML file)
-
-`docs/overview.html`: Loki Mode 10 explained in five views (Users, Engineers,
-Architects, Executives, Pitch), with Mermaid flow diagrams. It replaces the six
-legacy-era pages that used to live in `docs/walkthrough/`.
-
-## Demo Apps (6 HTML files)
-
-Located in `examples/`. Each was generated by Loki Mode from a single prompt.
-
-| File | Title | Description | Size |
-|------|-------|-------------|------|
-| `demo-saas-dashboard.html` | SaaS Dashboard | KPI cards, sparklines, revenue chart, activity feed | 9 KB |
-| `demo-task-manager.html` | Task Manager | Kanban board with drag-and-drop and localStorage | 9 KB |
-| `demo-chat-app.html` | Chat App | Real-time chat with typing indicators and auto-scroll | 8 KB |
-| `demo-landing-page.html` | Landing Page | Hero, features, pricing, FAQ accordion, newsletter | 15 KB |
-| `demo-portfolio.html` | Portfolio | Animated gradients, skill bars, project cards, contact form | 12 KB |
-| `demo-ecommerce.html` | E-Commerce | Product filters, sorting, star ratings, cart counter | 12 KB |
-
-## Product Website (1 HTML file)
-
-| File | Title | Description | Size |
-|------|-------|-------------|------|
-| `website/index.html` | Loki Mode Product Website | Full landing page with hero, terminal animation, features, pricing | 38 KB |
-
-## Summary
-
-| Category | Count |
-|----------|-------|
-| Overview | 1 |
-| Demo Apps | 6 |
-| Product Website | 1 |
-| **Total** | **8** |
-
-## Viewing Locally
-
-All files are self-contained HTML. Open directly in any browser:
-
-```bash
-# Open the overview
-open docs/overview.html
-
-# Open a demo app
-open examples/demo-saas-dashboard.html
-
-# Or serve the entire repo with a local server
-python3 -m http.server 8080
-# Then visit http://localhost:8080/docs/overview.html
-```
-
-## Design
-
-All interactive content shares these characteristics:
-
-- **Self-contained** -- Single HTML file with embedded CSS and JavaScript
-- **No build step** -- Open in any browser, works offline (except Google Fonts)
-- **Dark theme** -- Consistent dark design with purple accent (#553DE9)
-- **Responsive** -- Adapts to mobile, tablet, and desktop viewports
-- **No build step dependencies** -- No npm packages; `docs/overview.html` loads Mermaid from a CDN to draw its diagrams

package/docs/ENTERPRISE-IDENTITY-ROADMAP.md

@@ -1,206 +0,0 @@
-# Enterprise Identity Roadmap
-
-This document scopes Loki Mode's enterprise identity surface honestly. It
-separates what is shipped today from what is roadmap. Nothing in the
-"Roadmap" section ships today. Where a capability is not built, it is labeled
-as such, with a real effort estimate and the identity-provider (IdP) or test
-infrastructure it would require.
-
-The intent is to give a precise, non-aspirational picture so that marketing,
-sales, and docs never overstate the enterprise identity story.
-
-## 1. Current state (shipped, verified)
-
-Everything in this section is backed by code in `dashboard/auth.py` and
-`dashboard/server.py`. Function names are cited so claims can be checked.
-
-### Token authentication
-
-- Opt-in via `LOKI_ENTERPRISE_AUTH=true` (off by default).
-  See `ENTERPRISE_AUTH_ENABLED` and `is_enterprise_mode()` in
-  `dashboard/auth.py`.
-- API tokens are minted, hashed (per-token random salt, SHA-256), revoked,
-  deleted, and listed:
-  `generate_token()`, `revoke_token()`, `delete_token()`, `list_tokens()`,
-  `validate_token()`. Tokens are stored at `~/.loki/dashboard/tokens.json`
-  with enforced `0600` permissions (`_save_tokens()`).
-- Token validation iterates all entries with a constant-time compare to avoid
-  leaking token count via timing (`validate_token()` plus
-  `_constant_time_compare()`).
-
-### OIDC bearer-token validation (the closest foundation for SSO)
-
-- Opt-in via `LOKI_OIDC_ISSUER` + `LOKI_OIDC_CLIENT_ID`.
-  See `OIDC_ENABLED` and `is_oidc_mode()` in `dashboard/auth.py`.
-- Inbound JWTs are validated by `validate_oidc_token()`. When PyJWT +
-  cryptography are installed, signatures are cryptographically verified
-  (RS256/RS384/RS512) against the provider's JWKS endpoint, with issuer and
-  audience checks (`_get_oidc_config()`, `_get_jwks()`).
-- Without PyJWT, tokens are rejected unless `LOKI_OIDC_SKIP_SIGNATURE_VERIFY`
-  is explicitly set (insecure, local-testing only, loudly logged as critical).
-- Role/group claims are mapped to Loki roles by `_scopes_from_claims()` /
-  `_collect_role_claims()`, supporting generic `roles`/`groups`, Keycloak
-  `realm_access.roles`, AWS Cognito `cognito:groups`, and a configurable
-  claim (`LOKI_OIDC_ROLES_CLAIM`). Unrecognized claims fall back to the
-  least-privileged default role (`_default_oidc_role()`, default `viewer`),
-  never admin.
-
-  IMPORTANT distinction: this is server-side validation of a bearer JWT that
-  some other system obtained. Loki does NOT implement a browser login flow,
-  an authorization-code exchange, or an end-user SSO redirect. A separate
-  component must perform the user-facing sign-in and present the resulting
-  JWT to Loki.
-
-### Scopes and predefined roles (read/control style authorization)
-
-- Four predefined roles in `ROLES`: `admin`, `operator`, `viewer`,
-  `auditor`. Scope hierarchy (`_SCOPE_HIERARCHY`, `has_scope()`):
-  `*` -> `control` -> `write` -> `read`, plus `audit`/`admin`.
-- Endpoint enforcement via the `require_scope()` dependency factory and the
-  `get_current_token()` FastAPI dependency. When neither auth mode is enabled,
-  access is anonymous (local-first default).
-
-### Dashboard transport gating (added in Release A)
-
-- WebSocket auth gating: the dashboard validates a bearer token (header or
-  `?token=`/`?access_token=` query for browser clients) at the mount
-  boundary before delegating, mirroring the HTTP `get_current_token` order
-  (OIDC first, then loki token). See `_MountAuthGuard._validate_ws_token()`
-  and `_ws_token_from_scope()` in `dashboard/server.py`.
-- REST scope consistency: `/api/memory` and `/api/collab` endpoints were
-  brought in line with the read/control scope model so they are not reachable
-  unauthenticated when enterprise auth is on.
-- Webhook/trigger HMAC: the external trigger surface requires a shared secret
-  and rejects unsigned/mismatched requests (constant-time compare via
-  `hmac.compare_digest`, surfaced through `_constant_time_compare()`).
-
-### Tenant isolation (data-plane, present but minimal)
-
-- A `Tenant` model exists (`dashboard/models.py`: `class Tenant`, with
-  `Project.tenant_id` foreign keys) and the v2 API enforces a tenant boundary
-  derived from a trusted, server-validated `tenant:<id>` scope on the token
-  (`dashboard/api_v2.py`: `TENANT_SCOPE_PREFIX`). A non-admin token is pinned
-  to one tenant; cross-tenant requests are denied with 403; an un-scoped
-  token reaches no tenant-scoped resource.
-- This is project-level data isolation keyed off a token scope. It is NOT a
-  full tenant RBAC system (no roles per tenant, no per-tenant policy
-  administration, no tenant lifecycle management UI). See the roadmap below.
-
-### What the infrastructure OIDC is (and is NOT)
-
-The OIDC referenced in the Terraform and Helm assets is workload identity
-(IRSA on AWS / Workload Identity on GCP) used so the running pods can assume
-cloud roles. That is machine-to-cloud authentication, not end-user SSO.
-
-Likewise, Kubernetes RBAC and NetworkPolicy in the Helm chart govern what the
-cluster service accounts and pods may do. They are cluster-plane controls and
-are unrelated to product-level or per-tenant authorization for Loki users.
-Do not conflate cluster RBAC with application RBAC.
-
-## 2. Roadmap (NOT built)
-
-None of the items below are implemented. Each lists honest scope, a rough
-effort estimate, and the IdP or test infrastructure required.
-
-### SSO / SAML (browser sign-in flow)
-
-- Scope: a user-facing single sign-on flow. Two sub-paths:
-  - OIDC authorization-code login (closer to today's code): a browser
-    redirect to the IdP, code exchange, session/cookie issuance, and CSRF/
-    state handling. The existing `validate_oidc_token()` already validates the
-    resulting JWT, so this is the smaller of the two.
-  - SAML 2.0 (still common in large enterprises): SP metadata, ACS endpoint,
-    XML signature validation, NameID/attribute mapping, and IdP-initiated and
-    SP-initiated flows.
-- Effort: OIDC login flow on top of the existing validator is roughly a few
-  weeks (1 engineer) including session management and tests. Full SAML 2.0 is
-  larger, on the order of 1 to 2 months, because XML signature handling and
-  multi-IdP quirks are involved; using a vetted SAML library is mandatory
-  rather than hand-rolling.
-- Needs: a real IdP to test against (Okta, Azure AD/Entra ID, or Auth0; a
-  free developer tenant works for early dev). Integration tests must run
-  against that IdP, not mocks alone.
-
-### SCIM user/group provisioning
-
-- Scope: a SCIM 2.0 server so an IdP can create/update/deactivate users and
-  push group membership automatically, instead of users being created on
-  first login. Requires `/scim/v2/Users` and `/scim/v2/Groups` endpoints,
-  filtering, pagination, PATCH semantics, and mapping SCIM groups onto Loki
-  roles/tenants.
-- Effort: roughly 1 to 1.5 months (1 engineer) for a conformant subset plus a
-  persistence model for provisioned identities (today there is no durable
-  user store; OIDC users are derived per-request from claims).
-- Needs: a SCIM-capable IdP to drive the provisioning (Okta or Azure AD), plus
-  a SCIM conformance test harness. This depends on a real user-store model
-  landing first.
-
-### App-level / tenant RBAC
-
-- Scope: roles and policy that go beyond the current four global roles and
-  the `read`/`control` scope hierarchy. Concretely: roles scoped per tenant,
-  per-tenant policy administration, custom roles, resource-level permissions,
-  and an admin surface to manage them.
-- Current state to build on: `Tenant`/`Project` models exist and a
-  `tenant:<id>` scope pins a token to one tenant (data isolation). What is
-  missing: per-tenant role assignment, a policy model richer than the global
-  scope hierarchy, custom/role-definition management, and any UI for it.
-- Effort: roughly 1 to 2 months (1 to 2 engineers) depending on how much
-  policy flexibility is committed to (a fixed per-tenant role set is the
-  smaller end; arbitrary custom roles and resource-level rules is the larger
-  end).
-- Needs: no external IdP, but it pairs naturally with SCIM (group-to-role
-  mapping) and benefits from the durable user store noted above.
-
-### SOC2
-
-- Scope: SOC2 is a compliance PROGRAM, not a code feature. It spans durable,
-  integrity-protected audit logging with retention and SIEM export, access reviews,
-  change-management process, vendor management, security policies, and a Type
-  II observation window (commonly 6 to 12 months of evidence collected under
-  an auditor).
-- What exists today that helps but does not constitute SOC2: hash-chained
-  audit logging and syslog/SIEM forwarding (see the audit-logging docs). These
-  are inputs to an audit, not the certification.
-- Effort: multi-quarter organizational work, typically 6 to 12 months elapsed,
-  involving engineering, security, and an external auditor. It is not a sprint
-  and should never be represented as a shippable feature.
-- Needs: an auditor engagement, an evidence/observation window, and
-  organizational process, in parallel with (not blocking) the code items above.
-
-## 3. Sequencing recommendation
-
-1. OIDC authorization-code login flow first. It reuses the existing
-   `validate_oidc_token()` validator, is the smallest increment, and unlocks
-   the most common "we need SSO" enterprise requirement with the least new
-   surface. This is the natural next code step after today's OIDC bearer
-   validation.
-2. App-level / tenant RBAC next, building on the existing `Tenant` model and
-   `tenant:<id>` scope. Most mid-market and enterprise deals ask for "roles
-   and tenant isolation" once SSO is in place.
-3. SCIM after a durable user store exists (it depends on one). SCIM is a
-   larger-enterprise ask and is most valuable once SSO and RBAC are stable.
-4. SAML in parallel with or after the OIDC login flow, only when a target
-   account specifically requires SAML rather than OIDC. Many enterprises
-   accept OIDC, so do not build SAML speculatively.
-5. SOC2 runs as parallel organizational work, started early because of the
-   observation window, but tracked separately from the code roadmap. The
-   existing audit-log foundation is a head start, not a finish line.
-
-Rationale: OIDC login -> tenant RBAC -> SCIM is the path that unlocks the most
-enterprise deals soonest while reusing the most existing code. SAML is
-demand-gated. SOC2 is long-lead org work that should begin in parallel rather
-than block feature delivery.
-
-## 4. What we do NOT claim
-
-Loki Mode does NOT today ship: a browser SSO login flow, SAML support, SCIM
-provisioning, app-level or per-tenant RBAC beyond the global four-role / read-
-control scope model and the `tenant:<id>` data-isolation scope, or SOC2
-certification. The shipped identity surface is: opt-in token auth, opt-in OIDC
-bearer-token validation, a read/control scope model with four predefined
-roles, dashboard WebSocket and REST auth gating, webhook HMAC verification,
-and tenant data isolation via a token scope. Workload-identity OIDC (IRSA /
-Workload Identity) and Kubernetes RBAC/NetworkPolicy are infrastructure
-controls and are not end-user SSO or product RBAC. Any statement beyond this
-is roadmap, not a current capability.

package/docs/EVIDENCE-RECEIPT-BUILD-APPLICABILITY.md

@@ -1,79 +0,0 @@
-# Evidence Receipt: honest build applicability (done once, for all customers)
-
-## The defect (founder-reported, 2026-07-03)
-
-A sophisticated user built a Node CLI (invoice tool) and saw the Evidence Receipt say
-"Build: not run - build not run", "Live health check: not captured", "No screenshot",
-headline "Working, with gaps". He concluded *nothing was validated* -- and that read is the
-bug: it destroys trust in genuinely-validated work.
-
-## Ground truth (from the persisted proof of run-20260703034719)
-
-- `facts.tests` = `verified`, exit 0 -- tests GENUINELY ran and passed.
-- `facts.security` = `ran:true, clean` -- security GENUINELY ran, real clean scan.
-- `facts.build` = `ran:false, status:not_run, command:""` -- and this is counted as a GAP
-  by `_compute_degraded` (proof-generator.py:903-908), which forces "WITH GAPS".
-- `facts.quality_gates` = `[]` (EMPTY) -- verify.sh's deterministic build gate does NOT
-  reach the SaaS proof.
-
-## Root cause (systemic, every build, every customer)
-
-`build-results.json` has **NO writer**. `_collect_build` (proof-generator.py:319) reads
-`.loki/quality/build-results.json`, which nothing ever writes, so `facts.build` defaults to
-`not_run` (line 333) for EVERY build. The sibling collectors DO have writers in run.sh
-(`enforce_static_analysis` 8357, `run_secure_scan` 8720, `enforce_test_coverage` 9170 ->
-test-results.json / security-findings.json / static-analysis.json). Build was never wired.
-
-So "Build: not run" is not a per-project decision -- it is a permanent, structural
-mislabel. A build that has no build step (a CLI) and a build that genuinely skipped a real
-build both read identically as "not run" and both count as a gap.
-
-## The fix (honest, no fabrication, no mocking -- the founder's hard constraint)
-
-Add the missing writer as a sibling collector, with a POSITIVE applicability determination:
-
-1. **run.sh `enforce_build_check()`** (new, sibling to enforce_static_analysis): detect the
-   stack's build command (npm "build" script / go build / cargo build -- same detectors as
-   verify.sh:250-291). Then:
-   - build command exists -> RUN it -> record `{ran:true, command, exit_code, status:
-     verified|failed}`.
-   - genuinely NO build step for this stack -> record `{ran:false, applicable:false,
-     status:not_applicable, command:""}`. This is a POSITIVE "no build phase" signal, not an
-     absent file.
-   Write `.loki/quality/build-results.json`. Call it where the sibling collectors are called.
-
-2. **proof-generator.py `_collect_build`**: pass through `applicable:false` -> status
-   `not_applicable`. CRITICAL: `not_applicable` ONLY from an explicit `applicable:false` in
-   the file. File ABSENT or unknown status -> `not_run` (honest gap), NEVER N/A. Absent must
-   never mean N/A (that would flip un-built projects green -- fake-green).
-
-3. **proof-generator.py `_compute_degraded`**: `not_applicable` is NOT a gap (excluded from
-   the weak set for build). A failed/skipped/not_run build stays a gap. Mirror-image guard:
-   a real build script that FAILS still emits `failed` -> gap -> never green.
-
-4. **proof-generator.py status normalizer (line 215)**: `not_applicable` passes through.
-
-5. **SPA adapter.ts**: `not_applicable` renders "N/A - no build step for this stack" (a
-   neutral/pass tier, NOT a warn/gap), distinct from "not run".
-
-## Anti-fake-green invariants (the trust moat)
-
-- N/A ONLY on positive `applicable:false`. Absent file / unknown status -> honest gap.
-- A build script that got skipped or failed STILL shows a gap and CANNOT go green.
-- The directional regression test (write FIRST): Node project WITH a build script whose
-  build FAILS -> `facts.build=failed` -> degraded -> headline NOT green. And: build gate
-  MISSING -> still a gap, not N/A.
-- N/A does not gate the seal any more than a gap does; it is honest applicability, not a pass.
-
-## Measurable before/after
-
-Before: invoice CLI -> "Build: not run", headline "Working, with gaps".
-After: fresh invoice CLI build -> "Build: N/A (no build step for this stack)", tests passed,
-security scanned-clean, headline VERIFIED (no un-closed applicable gaps).
-
-## Constraints
-
-Verdict-core: council 3/3 + local-ci + 14 version locations. Verify via
-function-extraction/golden harness -- NEVER run the engine build from the worktree. Run the
-EXISTING tests/test_proof_generator.py green before AND after (it has build-results.json
-fixtures that this change touches). Deploy to live SaaS is `bun install -g loki-mode@<ver>`.