Rules

90-test security validation matrix for authentication, session management, RBAC, and data protection

Clean Code rules for error handling, concurrency, and unit testing

Enforce schema design, implementation process, and script conventions for all SBX code

Rules for curating LLM context windows — instructions, tools, state, and retrieval

Every design task is built outside-in: define the top-level contract BY EXAMPLE (input fixtures + expected outputs, including adversarial 'break it every way') BEFORE designing internals; stress-test and simplify; lock the simplest contract; then decompose one level down and RECURSE to the final primitive. Two gates apply at every step: never proceed below 90% confidence without asking; never fabricate data.

Data trace debugging pattern — Source → Transform → Result, never guess-fix

Test fixture creation, location, format, naming, and cross-cutting reuse across all test types

Enforce model-first development — model IS source of truth, implementation follows

Playwright-based UI verification — screenshot evidence, navigation testing, accessibility checks

State derivation from filesystem — no tracking files, idempotent operations, scan-based status

UI/UX design rules for spacing, typography, color, animation, responsive, accessibility, and grid

Core principles — Active Object Component, Build To Last, Creative Then Protocol Lock

Clean Code rules for boundaries, object/data design, systems, and emergence

Principles for organizing classes into components — REP, CCP, CRP

Systematic approach to software that handles misuse, invalid inputs, and infrastructure failures

Every piece of knowledge must have a single, unambiguous, authoritative representation

Components should be self-contained with minimal coupling to other components

SOLID — five design principles for flexible, testable, resilient software

Governance rules for LLM agent behavior within the SBX framework

Clean Code rules for functions, classes, formatting, comments, and naming

Standardize git commit messages as structured knowledge artifacts with full traceability to framework decisions, solutions, patterns, standards, goals, and trade-offs

Rules for importing UI components and animations from HTML prototypes into SBX component library

Completion criteria — evidence-based done: UI visible, tests passing, fixtures present, no silent claims

License review and dependency intake governance for all external libraries and packages

Define quality gates, requirements, and checklists for governed deployment of workspace projects

Docker Compose governance — no hardcoded values, env from managers, healthcheck patterns, overlay pattern

Documentation rules — pointers over duplication, live commands over static tables

Domain expert governance — FDD knowledge backbone adapted for SBX with tool, system, business, and data expert types

Environment variable governance — SBX_ prefix, resolution order, .env patterns, atomic generation

IBM ETVX (Entry-Task-Verification-Exit) phase gate methodology for task governance

The eight best practices that form the foundation of Feature-Driven Development

Feature sizing and expression rules — 2-week max, action-result-object naming

Design and code inspection practices in FDD for quality assurance

Maximum iteration length in FDD design/build cycles — 2 weeks

Every code-generated artifact MUST be unambiguous to a future reader — via filename infix, inline header, or hash. Three tools, chosen by the file's filename constraint.

ISO/IEC/IEEE 12207:2017 three-level process hierarchy for SBX framework governance

Define E2E testing conventions using Makefile for SBX scripts

Every workflow Makefile (Makefile.d/workflows/*.mk) MUST expose a `help:` target that documents its purpose, targets, vars, and usage examples. Tools .mk files are exempt (called by workflows, not by humans).

Name artifacts by structural purpose, never by app domain — validation rule at every SDLC step

Non-Functional Requirements (NFRs) are MUSTS for every feature touching user input, persistence, network, or shared state. They are not optional, not negotiable, and not 'skipped if not explicitly requested'. The right interpretation of scope-matched: refine WHICH NFR controls apply to a specific workload — NEVER skip NFR enforcement entirely.

Mandate owner-scoped, hierarchical object-storage (R2/S3) keys so every stored binary has a deterministic, traceable, owner-scoped URL

Operational guidelines for Claude Opus 4.6 sessions on SBX framework artifacts

Multi-platform protocol governance — model as truth, goal-driven functions, component level scoping

Centralized port allocation via sbx ports manager — no hardcoded ports, all from registry

Implementation matches the task's actual scope per SBX governance, clean code standards, security NFRs, and applicable workload. Build what is required — fully and properly. Skip what is not required. The balance is the work.

Canonical structure for the markdown body of every step.md in `.sbx/.framework/lifecycle/sdlc/`. Same skeleton across all 25 steps ensures deterministic LLM output regardless of which agent runs the step.

Define registry structure for Active Object components in SBX

Proof-of-work report template — every claim of done/working/fixed MUST include verifiable evidence

Workspace directory conventions — projects as containers, entities belong to projects, SBX as infrastructure