Document Type: Implementation Guide
Status: Implementation Guide
Version: v1.1
Authority: SIT Brain Canon
Applies To: SITengine v0.1 build handoff and minimal implementation discipline
Parent: SIT Brain Canon
Environment: Supabase + MWMS Executor
Last Reviewed: 2026-03-15
Purpose
This document defines the build handoff instructions for SITengine v0.1.
Its purpose is to ensure the first SIT engine implementation remains minimal, controlled, and structurally aligned with SIT governance.
SITengine v0.1 must:
• run manually
• perform defined integrity tests
• produce PASS or FAIL
• write exactly one immutable log record per run
No dashboards.
No automation loops.
No optimisation logic.
Scope
This implementation guide applies to:
• SITengine v0.1 only
• Supabase + MWMS Executor implementation path
• manual SIT test triggering
• immutable SIT log creation
• minimal PASS / FAIL execution discipline
This document governs the first implementation handoff for SITengine.
It does not govern:
• automated monitoring loops
• broader SIT dashboard design
• ongoing performance optimisation
• business-logic mutation
• compliance interpretation
• higher-version SIT automation features
Those remain outside v0.1 scope unless separately approved.
Definition / Rules
Pre-Build Validation Rule
Before building, confirm the following source documents:
• SIT Brain Canon
• SITengine v0.1 – Minimal Design Spec
• SIT Test Suite – v0.1
• SIT Log Schema
If anything conflicts:
STOP and escalate to HeadOffice.
Implementation Steps (Strict Order)
Step 1 – Create SIT Log Table
In Supabase, create table:
sit_logs
Minimum columns:
• id (uuid, primary key)
• run_id (text, unique)
• timestamp (timestamptz, UTC)
• engine_version (text)
• overall_result (text: PASS / FAIL)
• failed_step (text, nullable)
• failure_reason (text, nullable)
• task_id (uuid, nullable)
• step_results (jsonb, nullable)
• notes (text, nullable)
No additional required fields in v0.1.
Step 2 – Build Manual Trigger
Trigger options, choose one only:
• WordPress admin button
• REST endpoint
• direct executor task
Must NOT:
• run on cron
• run continuously
• auto-trigger
Step 3 – Execute Test Suite
Run tests in this order:
• Supabase connectivity test
• Tasks table read test
• Tasks table write test
• Smoke task end-to-end test
If any step FAILS:
• stop execution
• set overall_result = FAIL
• record first failed_step only
• do not continue after first failure
Step 4 – Write Log Record
Create exactly one log record:
• generate unique run_id
• capture timestamp (UTC)
• store engine_version = v0.1
• store overall_result
• store failed_step (if any)
• store failure_reason (if any)
• store step_results (optional JSON)
After insert:
• do not update the row
• do not modify fields
• do not delete
Output Rules
SITengine must output only:
PASS
or
FAIL
Optional:
short structured summary
Not allowed:
• persuasion
• explanation essays
• optimisation advice
Hard Constraints
SITengine v0.1 must NOT:
• block tasks automatically
• modify business logic
• interpret compliance policy
• optimise performance
• run automatically
• edit existing logs
It only reports evidence.
Acceptance Criteria
SITengine v0.1 is considered valid when:
• manual trigger works
• all 4 tests execute
• PASS / FAIL is returned correctly
• a valid sit_logs record is created
• log matches SIT Log Schema
• no other tables are modified
Validation Rule
If SIT appears to pass but logs are missing, treat as FAIL.
Integrity over appearance.
Drift Protection
The system must prevent:
• automatic triggering being introduced into v0.1
• extra functionality being added beyond the approved minimal scope
• multiple log rows being written for one run
• failed-step continuation after first failure
• post-insert mutation of SIT log records
• business logic changes being hidden inside the integrity runner
SITengine v0.1 must remain minimal, manual, immutable, and evidence-only.
Architectural Intent
SIT Build Handoff Pack exists to ensure the first SIT engine is built as a narrow integrity runner, not as an uncontrolled automation system.
Its role is to anchor the implementation around manual execution, first-failure stopping, immutable logging, and clean evidence output so SIT begins with structural trust rather than premature complexity.
Final Rule
If evidence is incomplete, the run is incomplete.
A passing appearance without an immutable log is a failure.
Change Log
Version: v1.1
Date: 2026-03-15
Author: MWMS HeadOffice
Change: Rebuilt page to align with the locked MWMS document standard for this cleanup pass. Preserved the original objective, source-document confirmation rule, strict implementation order, sit_logs minimum columns, manual-trigger restriction, test execution order, single-log-record rule, output rules, hard constraints, acceptance criteria, and integrity-over-appearance rule. Added Document Type, Version, Applies To, Parent, Last Reviewed, Purpose / Scope / Definition / Rules structure, Drift Protection, Architectural Intent, Final Rule, and standardised formatting.
Version: v1.0
Date: Prior entry preserved
Author: MWMS HeadOffice
Change: Initial SITengine v0.1 build handoff guide established.
END – SIT BUILD HANDOFF PACK v1.1