KATMA Project Creation Cycle Audit - Updated Post-Payment Run

Audit date: 2026-06-28

Target UI: https://app.katma.ru/

Report project slug: aud628report

Updated public report: https://aud628report.project.katma.ru/

This document records what actually happened in the live KATMA cabinet. It does not describe the intended design unless that behavior was observed in code, database state, logs, files, or public deployments.

Executive Result

After the Claude subscription was paid and re-tested, the core project factory worked for the successful classes:

• 9 projects reached published/public/prod live.
• All 9 public prod URLs returned HTTP 200.
• 9 successful builds had QUALITY_SCORECARD.json score=100 pass=true.
• Build queue concurrency was observed as 2 active jobs.
• Claude did not hit a new token/subscription limit during the post-payment run.

The process is still not fully reliable:

• 5 projects were stranded at intake tech_spec with only 3 artifacts: sensemaking, brief, prose.
• 2 projects generated an index.html and live mirror rows, but failed the multi-rubric scorecard and were not promoted to prod.
• A provider/API failure can be hidden inside an intake artifact or leave the session in a stage that the normal UI cannot recover.

Runtime Scope

The active cabinet is the PANEL stack under /WORK/PANEL/app.

Observed service roles:

• Caddy routes /api/* and /events/* to 127.0.0.1:3011.
• Caddy routes the UI to 127.0.0.1:3010.
• panel-api.service: Fastify API.
• panel-web.service: Next.js UI.
• panel-worker.service: BullMQ workers for build/deploy/edit/etc.
• panel-engine.service: non-root engine RPC.
• Static deployments use per-project nginx containers plus generated Caddy fragments.

Primary code paths:

• UI create screen: apps/web/app/projects/new/page.tsx
• Project detail/deploy UI: apps/web/app/projects/[id]/page.tsx
• Projects API: apps/api/src/routes/projects.ts
• Intake API: apps/api/src/routes/intake.ts
• Build enqueue and D48 guard: apps/api/src/lib/project-build.ts
• Quality spec: apps/api/src/lib/quality-spec.ts
• Quality contract: apps/api/src/lib/quality-contract.ts
• Worker wiring: apps/worker/src/index.ts
• Build runner: apps/worker/src/build.ts
• Deploy runner: apps/worker/src/deploy-job.ts
• Intake engine: packages/intake/src/pipeline.ts
• Routing policy: packages/operators/src/routing.ts
• Engine runner: packages/engine-core/src/run.ts

Provider Status

Initial run before payment:

• Claude Code returned 403 oauth_org_not_allowed.
• Intake artifacts still advanced, but their bodies contained the provider error text.
• Build jobs failed with build produced no index.html.

Post-payment check:

• Running Claude as katma-engine returned OK.
• Clean V2 projects produced real intake artifacts.
• Builds proceeded past plan/build/critique/quality-scorecard.
• No Claude subscription/token limit occurred during the post-payment audit window.

Stage Map

1. Authentication

Owner login uses session cookies, CSRF, and Telegram 2FA on a new device. /api/me returned 200 after login. All project automation reused that owner browser session.

2. Project Box Creation

API: POST /api/projects.

Observed side effects:

• project row inserted with state='created', visibility='private', deploy_target='mirror';
• per-project database/user created;
• database password stored through vault secret refs;
• project folder path assigned under /WORK/PANEL/projects/<slug>;
• prod and mirror subdomains assigned.

project_connections remained empty for these projects. The UI can suggest connections, but the cabinet did not automatically sew external connectors into the new project.

3. Intake

API:

• GET /api/projects/:id/intake
• POST /api/projects/:id/intake/prompt
• POST /api/projects/:id/intake/answer
• POST /api/projects/:id/intake/prose

Stages:

1. collect_prompt

2. sensemaking

3. brief

4. prose

5. final_questions

6. tech_spec

7. done

Model behavior:

• sensemaking and brief: claude-haiku-4-5
• prose and tech_spec: claude-sonnet-4-6
• Build worker routing can also select Claude Opus for verify/hard/final tasks through the routing policy.

Artifact trust:

• Intake writes trust='opinion'.
• It does not write verified facts.

4. Quality Spec and Packs

When intake completes, the API creates an approved project_quality_specs row from intake artifacts.

Observed build files include:

• BUILD_STRATEGY.json
• PROJECT_BRAIN.md
• PACKS_APPLIED.md
• PROJECT_ASSET_MANIFEST.json
• MECHANICS_STANDARD.json
• BROWSER_EVIDENCE.json
• QUALITY_SCORECARD.json
• evidence.manifest.json
• index.html

Common packs observed in PACKS_APPLIED.md:

• accessibility@1.0.0
• responsive-design@1.0.0
• frontend-testing@1.0.0
• final-review@1.0.0
• self-critique@1.0.0
• landing-conversion@1.0.0
• copywriting@1.0.0
• brand-voice@1.0.0
• web-craft@1.0.0
• app-architecture@1.0.0
• admin-panels@1.0.0
• api-design@1.0.0
• category-specific packs such as dashboard/automation/brand strategy constraints.

5. Build

The build worker uses BullMQ with concurrency 2.

Observed build stages:

• visual-preflight
• plan
• build
• critique
• quality-scorecard
• mirror publish
• done

The build prompt includes the owner brief, project brain, quality spec, selected packs, active mechanics standard, generated visual assets, and visual capability instructions. The worker can request visual assets through the owner panel API for icon/logo, hero/product/background/banner images, background removal, upscale, video assembly, and 3D model generation.

6. Quality Gate

The scorecard checks multiple rubrics:

• deterministic project eval;
• quality contract v2;
• browser evidence v2;
• strategy fit v2;
• asset provenance v2;
• lab standard v1.

Observed successful projects reached score=100 pass=true.

Observed repair loop:

• Some projects first failed scorecard, then the worker repaired and redeployed mirror.
• Example: aud628v2sm had a placeholder/layout issue and later finished with score 100.

Observed non-recovered scorecard failures:

• aud628v2adx: score 97, failed browser-evidence-v2.layout-overlap-audit; mobile nav item API Contracts was clipped.
• aud628v2bcx: score 91, failed browser-evidence-v2.layout-overlap-audit and strategy-fit-v2.brand-provenance.

These were not promoted to prod.

7. Mirror Deploy

Mirror deploy uses:

• staged artifact copy;
• per-project nginx container;
• Caddy fragment generation through the fenced deploy wrapper;
• local health check;
• deploys row with target mirror.

Failed scorecard projects can still have live mirror deploy rows. Mirror health is not the same as production readiness.

8. Prod Deploy and Visibility

Prod publication uses two separate owner-dangerous operations:

• POST /api/projects/:id/visibility { visibility: "public" } with project.visibility.public reauth;
• POST /api/projects/:id/deploy { target: "prod", confirmProd: true } with project.deploy.prod reauth.

Successful prod deploys set project state to published only after worker health check passes.

Post-Payment Run Matrix

Public Prod Verification

All promoted prod URLs returned HTTP 200:

• aud628v2lm: 200, 73939 bytes, https://aud628v2lm.project.katma.ru/
• aud628v2ld: 200, 62811 bytes, https://aud628v2ld.project.katma.ru/
• aud628v2pm: 200, 49768 bytes, https://aud628v2pm.project.katma.ru/
• aud628v2pd: 200, 45728 bytes, https://aud628v2pd.project.katma.ru/
• aud628v2sm: 200, 34714 bytes, https://aud628v2sm.project.katma.ru/
• aud628v2sd: 200, 76688 bytes, https://aud628v2sd.project.katma.ru/
• aud628v2rm: 200, 65187 bytes, https://aud628v2rm.project.katma.ru/
• aud628v2rd: 200, 70518 bytes, https://aud628v2rd.project.katma.ru/
• aud628v2am: 200, 56894 bytes, https://aud628v2am.project.katma.ru/

Failure Details

Intake tech_spec stranded state

Observed symptom:

• intake_sessions.stage='tech_spec'
• prose_ok=true
• artifacts only: sensemaking, brief, prose
• no pending user question
• no tech_spec artifact
• no build job

Observed causes:

1. INV-06A-8 secret scanner rejected generated tech_spec text and the API returned HTTP 500.

2. One detailed business path overlapped with panel-api.service restart/SIGTERM.

Code-level reason:

• runForward advances session stage to tech_spec before the LLM output is safely persisted as a tech_spec artifact and before build enqueue.
• If the request fails in that window, there is no normal UI recovery path.

False-positive examples from logs:

• token rotation
• password registration
• token rejected

These are normal technical phrases, not real secrets, but the scanner pattern treats them as potential secrets.

API restart incident

At 2026-06-28 19:21 UTC, panel-api.service received SIGTERM and entered shutdown while intake requests were running. During the window, Caddy returned 502 for API calls while the service was unavailable. The service recovered automatically. This incident interrupted part of the V2 creation flow and is included as real runtime evidence.

Business-control contamination

aud628v2bcx was intentionally constrained to a simple public business project. It passed intake, but PACKS_APPLIED.md shows that the LLM inserted a refusal-style paragraph about business consulting into the quality contract context. The cabinet still produced a site, but the quality context was polluted by the model response.

Deploy Results

The 9 green projects were made public and deployed to prod. Database evidence:

• projects.state='published'
• projects.visibility='public'
• deploys.target='prod'
• deploys.status='live'
• deploys.health_check_ok=true

Deploy result file:

• /WORK/PANEL/audit-cycle-20260628/data/v2-prod-deploy-results.json

Evidence Files

• Browser/session traces: /WORK/PANEL/audit-cycle-20260628/data/storage-state.json
• Original pre-payment traces: /WORK/PANEL/audit-cycle-20260628/data/*-trace.json
• V2 traces: /WORK/PANEL/audit-cycle-20260628/data/aud628v2*-trace.json
• Replacement run: /WORK/PANEL/audit-cycle-20260628/data/v2-replacement-traces.json
• Prod deploy results: /WORK/PANEL/audit-cycle-20260628/data/v2-prod-deploy-results.json
• URL and score summary: /WORK/PANEL/audit-cycle-20260628/data/v2-url-score-summary.json
• Project artifacts: /WORK/PANEL/projects/aud628v2*/
• User-facing report: /WORK/PANEL/audit-cycle-20260628/reports/index.html
• This technical report: /WORK/PANEL/audit-cycle-20260628/reports/technical-report.md

Bottom Line

The cabinet is a real autonomous project factory after the Claude subscription is active. It can produce and publicly deploy quality-gated static project outputs. The strongest observed path is: landing, presentation, site, research, and minimal AI automation.

The weak points are not cosmetic:

• intake tech_spec can strand a project without UI recovery;
• the secret scanner is too broad for generated technical specifications;
• business-oriented prompts can pollute the quality context with refusal text;
• scorecard repair is useful but not guaranteed;
• prod is gated correctly and does not happen without owner reauth and a build artifact.