John Operating System — Consolidated Rules (FR-1/2/3, ZAKONs, 5 Hard Constraints)

John Operating System — Consolidated Rules

All ZAKONI, CEO corrections, and operational rules in one place. When/then format. No changelog dates. Just rules.

DELEGATION

VERIFICATION

INFORMATION & KNOWLEDGE

COMMUNICATION & REPORTING

QUALITY GATES

TOOLS & INFRASTRUCTURE

MODEL BUDGET

INCIDENT RESPONSE

FINAL-REVIEW Checklist (added 2026-04-25, MC #9238)

These 3 checks complement the deterministic pre-dispatch-gate (Phase 2). They cover failure modes that require human judgment — not closeable by hooks.

Check FR-1: Integration signal semantics

For any plan or PR that creates or modifies an integration component (queue consumer, drain worker, backpressure gate, adapter, webhook handler, or any component that reads a field from an external or internal service), the following field must be explicitly present in the plan or design doc:

signal_semantics_verified_by: [specialist name]

The reviewer must confirm that the semantic meaning of each signal matches its actual use. "Signal semantics" means: is this field a diagnostic/informational value (internal server state, not actionable by this client) or a client-actionable gate signal (directly determines this component's behavior)?

Precedent — drain worker 2026-04-22 (Category F, petter-taxonomy.md): pipeline_busy: true is a server-internal diagnostic field. The drain worker treated it as a client-side blocking gate. LightRAG continued accepting HTTP 202 responses while the drain worker was stopped. The bug produced no syntax error, passed design review, and surfaced only under real load. Gate logic semantic review would have caught this before merge.

Apply this check during: code review, plan review, and pre-publish-validate.sh for any plan that declares integration components.

Source: /tmp/9223-petter-taxonomy.md Category F; /tmp/9223-final-synthesis.md Section 2 New Gap B.

Check FR-2: Empirical constants

Every timeout, threshold, retry-count, or queue-depth constant in any delivered plan or implementation must cite its measurement source inline.

Required citation format: "observed [p99|p95|max] = [value], set [constant] to [value] with [N]% headroom"

Acceptable measurement sources:

Unacceptable — must be flagged in review:

Precedent — drain worker 2026-04-22 (Category G, petter-taxonomy.md): timeout constants 5s and 15s were guessed from training priors. Correct values, discovered only after production failure, were 45s and 60s respectively — a 9x and 4x error. This category of failure passes all plausibility checks. It requires specialist review with an explicit "where did this number come from?" question for every constant.

This check applies during: FINAL-REVIEW, Proveo acceptance test planning (to confirm pressure test scope matches the threshold being validated), and Mehanik Phase A (ARGS) when an integration component or queue worker is in scope.

Source: /tmp/9223-petter-taxonomy.md Category G; /tmp/9223-chip-llm-failure.md Section 3.3 (unjustified numerical precision); /tmp/9223-final-synthesis.md Section 2 New Gap C.

Check FR-3: Plan-completeness MC task IDs

The plan-completeness-gate hook (settings.json lines 111-113) checks for keyword presence of "Proveo" and "Skillforge" in plan files. This check is necessary but not sufficient. A plan that says "Proveo will validate" without an associated MC task ID passes the keyword gate but provides no actual commitment — the validation work has not been scoped, assigned, or scheduled.

Requirement: Every Proveo validation entry and every Skillforge documentation entry in any plan must reference a real MC task ID.

Valid format: "Proveo validation: MC #9233 (Angie Jones, E2E + pressure test)" Invalid (will be flagged): "Proveo will validate this", "Proveo coverage: yes", "Skillforge docs planned"

The reviewer must verify that the referenced MC task IDs exist and are not closed or cancelled: node ~/system/tools/mc.js show <id>.

Precedent — drain worker incident: Proveo Phase 1 validation (MC #8294) covered "does it ingest one document?" The scope did not include pressure testing under 500+ queued documents or slow LightRAG conditions. The task ID existed but its scope was too narrow. The task ID requirement is necessary but not sufficient — scope must also be verified against the known failure modes of the component being validated.

This closes the shallow grep-based plan-completeness-gate gap (Category G, Review Scope Blindness) where review scope is too narrow to catch real failure modes even when keywords are present.

Source: /tmp/9223-petter-taxonomy.md Category G; /tmp/9223-final-synthesis.md Section 2 Gap 8 (gap upgraded).

When this checklist applies

These checks are NOT closeable by deterministic hooks. They require specialist judgment. Do not attempt to automate FR-1 through FR-3 into pre-dispatch-gate.sh — the synthesis explicitly rejected this (see /tmp/9223-final-synthesis.md Section 4, Category F and G verdict: "Not addressable by rules alone. Requires specialist review with an explicit gate logic semantic checklist").

Source

/tmp/9223-final-synthesis.md Section 2 (gap audit, New Gaps B and C) and Section 5 (residual risks, Risk 5); /tmp/9223-petter-taxonomy.md Categories F and G; /tmp/9223-chip-llm-failure.md Section 3.3 (empirical validation — drain worker as Category G example).

ZAKON #30: H-Task Completion Requires Direct Probe (enforced)

Before marking ANY H-priority or BLOCKER task done, John MUST:

  1. Run a direct machine probe appropriate to the task type:
    • Deploy/service: curl -sI <URL> and verify HTTP 200 (not just trust subagent text)
    • Auth flow: curl POST /auth/login with real credentials and verify HTTP 200 + JWT
    • Data migration: SELECT COUNT(*) and verify expected row counts
    • Build: gh run list --limit 1 and verify conclusion=success
  2. Evidence-contract-validator.sh must return CONFIRMED for the subagent verdict.
  3. Both conditions required — neither alone is sufficient.

Violation: John marks H-task done citing only subagent text report without direct probe → mc.js done gate BLOCKS. Override requires --force + --reason with direct probe evidence.

Enforcement

Genesis

MC #99595 (Proveo fabricated PASS, John accepted without probe, CEO caught via 403 FORBIDDEN). MC #99651 (this ZAKON).

Board decision OCD-2: BEHAVIORAL + ARCH — both layers required. Hook enforces structure, ZAKON binds behavior.

Full ZAKONI text: ~/system/rules/zakoni-full.md (22 rules, #0-#22)

Revision #1
Created 2026-07-28 17:49:15 UTC by John
Updated 2026-07-28 17:49:15 UTC by John