kircérta // 2026 // consolidated recommendations

Build Now. Harden Next. Operate Safely.

PLAN IS BUILDABLE • ADD OPS/GOV FOR LONG RUN • KEEP BACKEND AS TOOL • GATE EXTERNAL PUBLISH

Verdict: the current plan is sufficient to start building (and validate the loop), but to run stably long-term and feel safe even when away from the computer, you should add: authz, concurrent SSOT writes, an audit query surface, a tool policy engine, failure degradation, and resource-leak soak tests.

Summary_

BIG SECTIONS / FLOWCHART INCLUDED

static html • copyable blocks

0) Verdict

YES TO BUILD. ADD MODULE-6 FOR OPS/GOV.

Your Modules 1–5 are sufficient to support “from 0 to 1” construction and verification (SSOT/Backend/SSE/Webhook/Protocol/Stability). But to achieve the goal of "long-term operation + you can see the evidence even when you are away from the computer", it is recommended to complete Module 6 (Ops & Governance) and integrate permissions, concurrency consistency, audit queries and tool thresholds into the infrastructure.

Already well-covered

Module 1: Minimum loop (simulate with ./ssot first)
Module 2: SSE + Dashboard (observability first)
Module 3: Webhook signature verification + idempotency approach
Module 4: ACK echo / criterion_ref / fidelity audit
Module 5: Load testing + timeout/heartbeat direction

Recommended additions (Module 6: Ops & Governance)

authz: unify roles/scopes (approve/tools)
Concurrent SSOT writes: base_sha optimistic lock + conflict handling
Audit query surface: query by task/correlation/type
Tool policy engine: hard gate external_publish + audit
Failure degradation: explainable paths for missing auth/OBS off/network down
Resource leaks: SSE long-connection + periodic screenshot/recording soak tests

1) Suggestion list (organized version)

WHAT TO ADD WITHOUT BREAKING YOUR RULES

The following enhancements will not change your basic boundaries: Backend still only does infrastructure (reading and writing/broadcasting/sign verification/execution tools), and policies are still in Coordinator; all side effects must be auditable.

A) Identity and permissions (authn/authz)

Unify scopes: admin/observer/tool_runner
approve/reject must have admin scope
tools are graded by side_effect_level; external_publish requires approval
Write audit for each request: who/when/what/result

B) SSOT concurrency and consistency

Write carries base_sha (optimistic locking)
Conflict: retry/deny + audit_event:write_conflict
Webhook deduplication: event_id + window
Reject old events (timestamp/sequence number) to avoid rollback

C) Audit query surface (read-only)

GET /api/audit?task_id=&type=&since=
Aggregate a tool link by correlation_id
dashboard evidence panel: screenshot/video/log + hash

D) Tool governance (policy + evidence)

policy engine: external_publish denied by default
Evidence package: artifacts[] + sha256 + timestamps + links
Failure must be structured: error_code + remediation_hint
Downgrade strategy: Upload failure → retain local evidence + notification

2) Build a flow chart

MODULE 1–5 + TOOLS TRACK + MODULE 6 (OPS/GOV)

The main line maintains its original order; Tools serves as a parallel track; and Module 6 serves as an "online-level fill-in" to ensure that you can keep track of the progress through evidence and auditing even when you are away from the computer.

FLOWCHART (STATIC SVG)

NOTE: TOOLS MUST WRITE AUDIT + SSOT; EXTERNAL PUBLISH REQUIRES APPROVAL.

3) Module 6 specifications (recommended to add)

A SMALL MODULE THAT MAKES THE SYSTEM OPERABLE

This is not about "making the backend smarter", but about solidifying governance capabilities: permissions, concurrency consistency, audit queries, and external side effect thresholds. Everything is consistent with the original security code: the infrastructure is responsible for gates and records, and the policy is still determined by the Coordinator.

Deliverables

authz middleware（scopes + audit）
SSOT writer: base_sha optimistic locking + conflict handling
audit query API: read-only retrieval
tool policy engine：external_publish gate
evidence panel: dashboard displays evidence package

acceptance

external_publish will be rejected if not approved + audit_event:policy_denied
Concurrent write conflicts are reproducible + audit_event:write_conflict
audit can review a link based on correlation_id
The dashboard can view screenshots/videos/logs and hashes with one click

You are the Codex (executor). Please add Module 6 (Ops & Governance) so that the system can run for a long time.

Hard constraints:
- Do not change the existing boundaries: the backend is still the infrastructure (tool layer), and no intelligent judgment is written; the strategy is in the Coordinator.
- But the backend must enforce permissions and policy gate (this is an infrastructure responsibility).
- All rejections/failures/conflicts must be written to audit (JSONL).

Task:
1) AuthN/AuthZ：
- Added token scopes (admin/observer/tool_runner).
- approve/reject admin only.
- /api/tools/execute requires tool_runner; external_publish additional gate (see point 3).
- Write audit: actor/scope/route/status/correlation_id for each request.

2) SSOT concurrent writing (supported by GitHub or local simulation):
- Write requests carry base_sha (or version number).
- If there is a conflict, reject it and write audit_event:write_conflict, and return retry information.

3) Tool Policy Engine：
- tool_call must contain side_effect_level.
- external_publish is denied by default; only executed if task.allow_external_publish=true and admin_approved=true.
- policy_denied must also write audit_event:policy_denied.

4) Audit Query API (read-only):
   - GET /api/audit?task_id=&type=&since=
- GET /api/audit/{correlation_id} returns link aggregation.

5) Dashboard Evidence Panel (can be simplified):
- Show demo_evidence: screenshots/videos/logs + sha256 + links.

acceptance:
- Not Approved external_publish: 100% Denied and write policy_denied.
- Concurrent write conflicts are reproducible and the system does not roll back to the state.
- Audit query enables complete review: one correlation_id → all events and artifacts.