Product Proof Setup · GoingNinja Manual Knowledge Wiki

1. Setup Goal

The proof case must not start from hidden shell luck.

Before product work counts as real proof, a newcomer must be able to answer:

which accounts own the repo, preview, and domain
which tokens or CLI sessions already exist
which checks prove those credentials are really available
how local work becomes a protected hosted preview

If those machine surfaces are still unfamiliar, read:

2. What Must Exist Before Machines Can Work

Tagnova does not redefine the setup baseline. It inherits the canonical provider baseline from Before You Start and the hosted-preview rule from Deployment And Access.

For the proof case, the product-specific additions are only:

the domain plan for tagnova.news, www.tagnova.news, and www.preview.tagnova.news
the explicit preview protection rule for www.preview.tagnova.news
the staged multi-repo audit workspace for cross-repo audit lanes

3. How To Verify Provider Access And Key Loading

The safest rule is:

do not print raw secret values
prove readiness by status checks, not by echoing tokens

Use these checks in order.

3.1 Global readiness check

Run this from goingninja-os:

npm run access:check

This verifies two things:

the required CLIs exist on the machine
the default provider entries required by the OS are present in the expected local stores

3.2 Provider registry check

Run:

./scripts/load-global-providers.sh check

The output is explicit:

ready(session) means the provider CLI session exists
ready(keychain) means the token exists in the expected keychain entry
missing(...) means the machine is not ready for that provider

3.3 Export check for the current shell

Run:

eval "$(./scripts/load-global-providers.sh exports)"

This loads the registered provider values into the current shell without copying them into Git.

If a later command still fails after that export step, the usual problem is not "the key exists somewhere" but "the key is not actually in the active shell for this process."

3.4 GitHub session check

Run:

gh auth status

This proves the local GitHub session itself is alive.

3.5 Repo-machine boundary

One more distinction matters:

local shell exports are for your current local process
GitHub Actions secrets are for the machines in CI
runtime secrets are for the app itself

Those are different boundaries. Do not assume that a token loaded locally is automatically available inside GitHub Actions or inside the deployed product.

3.6 Staged audit workspace check

For system audits, one more boundary matters:

the reviewer CLI needs one deterministic workspace
not a giant parent volume
not a symlink hop into several repos

Run this from goingninja-os:

npm run audit:stage -- \
  --name tagnova-proof-system-audit \
  /Volumes/Projekt/Projekt-GoingNinja/Repository/goingninja-manual \
  /Volumes/Projekt/Projekt-GoingNinja/Repository/goingninja-os \
  /Volumes/Projekt/Projekt-Tagnova/Repository/tagnova

This creates a copied workspace under ~/.goingninja/audit-workspaces/ and writes AUDIT_WORKSPACE.json with the exact staged paths and snapshot refs. That is the path reviewers should receive for a cross-repo audit lane.

4. Local, Branch, Preview, And Live

GoingNinja treats these as separate stages:

local clone with local .git
feature branch and push
PR checks and review lanes
merge into main
pre-launch hosted continuity preview on www.preview.<product-domain>
explicit launch on the public host

The important point is that the protected preview is not the same thing as:

a local preview
a raw provider preview URL
the public production host

5. Preview Access Rule

Before public launch, the hosted continuity state belongs on:

www.preview.<product-domain>

That host stays behind Cloudflare Access.

The repo must make these items explicit:

preview hostname
protection mode
allowlist source for approved emails or identity groups
branch-to-preview flow

For generated product repos, the declarative source now lives in:

ARCHITECTURE_REQUIREMENTS.json

The preview allowlist itself should not live as chat memory or as a dashboard-only habit.

6. Tagnova Setup Snapshot

Repo And Pipeline

active repo: local repo /Volumes/Projekt/Projekt-Tagnova/Repository/tagnova
continuity branch: main
pre-merge pipeline: .github/workflows/pr-audit.yml for PR checks and review lanes
post-merge pipeline: .github/workflows/post-merge-state.yml for trusted post-merge rendering of every state view on main

Runtime And Preview

public runtime: web/ SvelteKit app
local preview proof: verified locally on /, /why, and /today
hosted preview domain: target is www.preview.tagnova.news behind Cloudflare Access; explicit Vercel plus DNS contract is the next bounded step before that host can go live
system audit workspace: staged with npm run audit:stage -- --name ... from goingninja-os before cross-repo external review

Review Surfaces And Billing

current proof builder surface: a local Codex-backed execution surface in this environment; the platform contract does not require one exclusive builder vendor
blocking review CLI: Claude Code v2.1+
broad risk CLI: Gemini CLI v0.37+
current workflow actions: anthropics/claude-code-action@v1, google-github-actions/run-gemini-cli@v0
model pinning: no explicit Claude or Gemini model ID is committed yet; the repo currently pins action families and lanes, not exact model names
billing shape: GitHub Actions minutes bill to the repo owner; Claude bills to the Anthropic workspace behind its API key; Gemini bills to the Google billing context behind its API key; deployment bills to the selected hosting provider