# 693 Stateless Software Engineering Framework 7e735de5 > Stateless Software Engineering Framework - Skill: `tools-only/693-stateless-software-engineering-framework-7e735de5` (Agent Skill, multi-file: 3 files) - Install (CLI): `npx skillmds@latest add tools-only/693-stateless-software-engineering-framework-7e735de5` - Raw SKILL.md: https://api.skillmd.com/api/skills/tools-only/693-stateless-software-engineering-framework-7e735de5/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Research & Search - Author: tools-only (https://skillmd.com/u/tools-only) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/tools-only/693-stateless-software-engineering-framework-7e735de5 --- # Stateless Software Engineering Framework **Date**: 2026-01-25 **Status**: Design Document **Purpose**: Define a constraint-driven development framework that compensates for LLM limitations through architectural structure rather than model capability --- ## Executive Summary This framework treats Claude as a **stateless computation engine** rather than a knowledge worker. Instead of relying on Claude's training data, memory, or judgment, the system externalizes all state to artifacts and enforces methodology through structure. **Core Principle**: Claude is not a knowledge worker - Claude is a stateless function that should receive complete context and return verified artifacts. ## What We Mean by "Stateless" Statelessness in this framework refers to **execution-time task context completeness** and **artifact-grounded verification loops**. Each agent receives a task with complete context - nothing to guess, nothing to recall from training data, nothing to infer from earlier conversation. The agent executes the task, produces verified artifacts, marks the task complete, and that session ends. **Key principle**: The execution context from one agent session is NOT passed to another session or agent. Each agent does exactly one task, then terminates. All state transitions happen through artifacts, not through conversation history or shared context. **What this eliminates:** - Guessing from incomplete information - Relying on training data priors - Carrying forward errors from earlier context - Context window degradation across tasks **What this enforces:** - Complete task specifications with all answers embedded - Artifact-based state transitions between stages - Independent verification at boundaries - Fresh context = fresh start = consistent quality --- ## Part 1: The Problem ### 1.1 Claude's Fundamental Limitations | Limitation | Manifestation | Impact | | ------------------------------------- | ----------------------------------------------------------------------------------------------- | --------------------------------------- | | **Long-context degradation** | Performance often drops as context grows; relevant info can be missed in long contexts | Long tasks produce poor results | | **Training data staleness** | Knowledge cutoffs vary by model/version; details can be outdated for fast-moving libraries/APIs | Incorrect or obsolete solutions | | **Miscalibrated confidence** | Models can sound confident while being wrong, especially under ambiguity or underspecification | Skips verification, ignores methodology | | **Completion optimization** | Optimized for "appearing helpful" over "being correct" | Takes shortcuts to show progress | | **Unreliable uncertainty estimation** | Often fails to reliably detect when evidence is missing (“doesn’t know when it doesn’t know”) | Proceeds with wrong assumptions | | **Goal displacement** | Optimizes for task metrics, not actual success | Disables tests, ignores lint rules | #### 1.1.1 What “hallucination” means (operationally) The term “hallucination” is used loosely. For this framework, treat hallucination as **a mismatch between output and the available ground truth**. Common operational definitions: - **Ungrounded claims (premise-based factual consistency)**: a response contains claims **not supported by provided context/premise**. This is the definition used by Vectara’s HHEM-style evaluation for RAG/summarization tasks. Source: [Vectara deep dive](https://www.vectara.com/blog/hallucination-detection-commercial-vs-open-source-a-deep-dive) (accessed 2026-01-26). - **Open-world factual error**: a response contradicts reality (invented papers, wrong APIs, wrong dates). - **Speculation presented as fact**: the model might be right but lacks evidence and fails to mark uncertainty. - **Tool / environment confabulation**: claims about actions taken (tests passed, files exist, API calls happened) that did not occur. Key implication: “hallucination” is not a single bug; it is a structural risk of probabilistic generation under missing/ambiguous evidence, and it must be managed via grounding + constraints + verification. #### 1.1.2 Hallucination is often a failure of constraints (not just missing knowledge) A recurring “felt experience” with LLMs: the output looks coherent and confident, but it _drifts_ into invented detail once the prompt becomes under-constrained. - **Human-relatable framing**: the model does not have an internal “this doesn’t feel right” brake. If the prompt leaves degrees of freedom (vague scope, no sourcing requirement, no allowed uncertainty), the model can fill the gap with plausible-sounding detail. - **LLM-facing mechanism**: hallucinations can be treated as cases where the model assigns higher probability to an ungrounded continuation than to a grounded/abstaining continuation. Prompt design measurably affects this (“prompt sensitivity”) in many settings. Source: [Survey and analysis of hallucinations in large language models (Frontiers 2025)](https://www.frontiersin.org/journals/artificial-intelligence/articles/10.3389/frai.2025.1622292/full) (accessed 2026-01-26). - **Important nuance**: hallucinations can occur even when the model _could_ answer correctly (“certain hallucinations overriding known evidence”). Source: [Trust Me, I’m Wrong: LLMs Hallucinate with Certainty Despite Knowing the Answer (EMNLP Findings 2025)](https://aclanthology.org/2025.findings-emnlp.792/) (accessed 2026-01-26). Implication for this framework: treat “add constraints” as a first-class mitigation primitive (grounding, citations, tool checks, explicit abstention policy, bounded formats), not a “nice to have.” #### 1.1.3 Why models guess instead of saying “I don’t know” (incentives matter) Another human-relatable failure mode: the model outputs _something_ even when it should abstain. A key driver is **how models are trained and evaluated**: - Many common benchmarks and scoreboards emphasize **accuracy** (right vs wrong) while under-weighting (or ignoring) the difference between **abstaining** and making a **confident error**. - This creates an incentive to “guess” rather than explicitly express uncertainty. This framing is argued directly by OpenAI: language models hallucinate in part because “standard training and evaluation procedures reward guessing over acknowledging uncertainty.” Source: [Why language models hallucinate (OpenAI, 2025-09-05)](https://openai.com/index/why-language-models-hallucinate/) (accessed 2026-01-26). Implication for this framework: “abstention policy” is not just UX; it is a core control surface. Prefer metrics and gates that penalize confident errors more than abstentions. ### 1.2 Observed Failure Modes **Claude will prefer to:** - Disable a failing test rather than fix the underlying bug - Change linting rules to ignore a smell rather than fix the code - Skip prerequisites to show faster progress - Use training data patterns rather than read actual documentation - Drift toward narrative/story-like completions when the prompt is under-constrained (fluency wins unless something pushes back) - Rationalize out of following CLAUDE.md instructions - Complete the task incorrectly rather than block on missing information **Root Cause**: Claude is optimized for user satisfaction signals, not correctness. Completing tasks (even badly) generates positive feedback. Blocking on prerequisites generates negative feedback. ### 1.3 Why Passive Approaches Fail | Approach | Why It Fails | | ---------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **CLAUDE.md instructions** | Claude rationalizes out of following them immediately | | **Asking Claude to verify** | Self-critique / self-verification is unreliable without external evidence ([OpenReview](https://openreview.net/forum?id=4O0v4s3IzY), [arXiv:2502.15845](https://arxiv.org/html/2502.15845v1)) | | **Training data skepticism rules** | Claude acknowledges the rule then ignores it | | **Self-reflection prompts** | Calibration/uncertainty can improve or worsen; not reliable as the primary control ([arXiv:2506.18183](https://arxiv.org/html/2506.18183v2), [arXiv:2506.00582](https://arxiv.org/html/2506.00582v2)) | | **One-shot complex tasks** | Context pressure causes quality collapse | **Key Insight**: Behavioral instructions cannot override architectural limitations. The solution must be structural, not instructional. --- ## Part 2: The Architectural Solution ### 2.1 Core Design Principles | Principle | Implementation | Rationale | | ------------------------------ | -------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------- | | **Stateless agents** | Each agent gets fresh context with exactly what it needs | Eliminates context pressure and accumulated errors | | **Externalized memory** | All state lives in artifact files, not in conversation | Survives session resets, enables verification | | **Single responsibility** | Each agent does exactly one thing | Reduces complexity, enables specialization | | **Message passing** | Agents communicate via artifacts, not shared context | Decouples stages, creates audit trail | | **Verification at boundaries** | Every stage validates previous stage's output | Catches errors before they propagate | | **Durable coordination plane** | Represent work as a task queue with explicit ownership + dependencies; coordinate via structured messages (inboxes) | Enables swarms/pipelines without shared context; makes “who is doing what” inspectable | | **Deterministic backpressure** | Gate progress on deterministic checks (build/tests/lint/security scans) executed by tools/scripts, not “advice” in prompts | Converts non-deterministic generation into a measurable loop that can converge | | **Embedded methodology** | The process IS the prompt, not instructions to follow | Cannot skip what structures the task | | **No recall required** | Task files contain all answers needed for the task | Reduces reliance on unverified recall; still requires verification for synthesis/logic | #### 2.1.1 Deterministic backpressure: inner loop vs outer loop Human-relatable framing: you can’t “prompt” your way into determinism. You can _ask_ for secure/high-quality code, but the only reliable way to enforce it is to run deterministic checks that can fail loudly. - **Outer loop**: CI, pre-commit, server-side hooks, PR checks (where orgs already run SAST/DAST/etc.). - **Inner loop**: the agent’s local generate→check→repair loop (fast feedback). Field perspective (note: the full post is subscriber-only; only the intro is publicly visible): - Huntley argues that “rules” in the context window (Cursor rules / AGENTS.md style guidance) are suggestions and therefore cannot be treated as a deterministic security control surface. Source: [anti-patterns and patterns for achieving secure generation of code via AI (Huntley, 2025-09-03)](https://ghuntley.com/secure-codegen/) (accessed 2026-01-26). Research perspective: - In code, “hallucination” often means “looks plausible but fails execution/requirements,” which motivates execution/test-based verification loops. Source: [CodeHalu (arXiv:2405.00253)](https://arxiv.org/html/2405.00253v4) (accessed 2026-01-26). - Secure code generation can be improved via an agentic workflow that applies guidelines and uses unit tests as a feedback mechanism to preserve functionality while improving security. Source: [SCGAgent (arXiv:2506.07313)](https://arxiv.org/html/2506.07313v1) (accessed 2026-01-26). Practical implication for this framework: - Treat “run deterministic checks” as a mandatory self-verification step in Stage 5 (Execution). If checks fail, the next loop iteration must incorporate the tool output as ground truth and repair until the checks pass or the task is explicitly blocked. #### 2.1.2 Storage-agnostic semantic tokens (artifact IDs, not file paths) This framework is intentionally storage-agnostic. Any concrete filename or path (e.g. `design-guide.md`, `task-{N}.md`) should be treated as an _example implementation_, not the canonical representation. The canonical representation is a semantic identifier that can be backed by files, a database, a queue, git notes, etc. **Core token pattern**: ```text ARTIFACT:{TYPE}({SCOPE_OR_ID}) ``` **Minimal starting set (recommended)**: ```text SCOPE:{scope_id} ARTIFACT:DISCOVERY(SCOPE:...) ARTIFACT:PRD(SCOPE:...) ARTIFACT:NFR(SCOPE:...) ARTIFACT:ARCH(SCOPE:...) ARTIFACT:ADR(DECISION:...) ARTIFACT:PLAN(SCOPE:...) ARTIFACT:TASK(TASK:...) ARTIFACT:EXECUTION(TASK:...) ARTIFACT:REVIEW(TASK:...) ARTIFACT:VERIFICATION(SCOPE:...) # Optional (often useful in practice) ARTIFACT:STATE(SCOPE:...) ARTIFACT:CONTEXT(SCOPE:...) ``` **Disambiguators (recommended)**: ```text CTX:WINDOW | CTX:CODEBASE | CTX:CONVERSATION | CTX:INTEGRATION PREREQ:AVAILABLE | PREREQ:DERIVABLE | PREREQ:MISSING | PREREQ:CONFIDENCE(0.0-1.0) EXEC:SEQUENTIAL | EXEC:PARALLEL | EXEC:WAVE VERIFY:SELF | VERIFY:BOUNDARY | VERIFY:FORENSIC | VERIFY:FINAL ``` **Terminology note (names unset, semantics fixed)**: - Use `CTX:*` for “what information is loaded/available to an AI instance” (context window vs codebase grounding vs conversation state). - Use `VERIFY:*` for _checks_ (deterministic or evidence-based) that gate progress. - Use `REVIEW` (as an artifact type) for _adjudication outputs_ (a human-meaning decision with rationale), even if the stage name later becomes “validation”, “forensic review”, “outcome review”, etc. - This framework explicitly avoids tool blocking and approval gates. All approval is frontloaded via explicit agreement on `Desired outcome` + `Objectives` + `Acceptance criteria`. After that, progress is gated only by prerequisite completeness (`PREREQ:*`) and check outcomes (`VERIFY:*`), not by “permission to use tools”. **Agent taxonomy (names unset, roles fixed)**: - An **agent** is any AI instance doing work and capable of using tools. - The **assistant** is the interactive agent in the main conversation. - A **sub-agent** is an agent invoked via the built-in `Task()` tool (isolated context, returns findings). #### 2.1.3 Example implementations (files vs SQL) The tokens are canonical; the storage backend is an implementation detail. Two equivalent example backends: **Example scope/task IDs**: ```text SCOPE:scope_001 TASK:task_042 ``` **A) Filesystem-backed artifacts (example convention)**: ```text ARTIFACT:DISCOVERY(SCOPE:scope_001) -> .sam/artifacts/scope_001/discovery.md ARTIFACT:PLAN(SCOPE:scope_001) -> .sam/artifacts/scope_001/plan.md ARTIFACT:PLAN(SCOPE:scope_001) -> .sam/artifacts/scope_001/plan.contextualized.md ARTIFACT:TASK(TASK:task_042) -> .sam/artifacts/tasks/task_042.md ARTIFACT:EXECUTION(TASK:task_042) -> .sam/artifacts/tasks/task_042.execution.md ARTIFACT:REVIEW(TASK:task_042) -> .sam/artifacts/tasks/task_042.review.md ARTIFACT:VERIFICATION(SCOPE:scope_001) -> .sam/artifacts/scope_001/verification.md ``` **B) SQL-backed artifacts (example schema)**: ```sql CREATE TABLE artifacts ( token TEXT PRIMARY KEY, type TEXT NOT NULL, scope_id TEXT, task_id TEXT, content TEXT NOT NULL, created_at TEXT NOT NULL, updated_at TEXT NOT NULL ); CREATE INDEX artifacts_scope_idx ON artifacts(scope_id); CREATE INDEX artifacts_task_idx ON artifacts(task_id); ``` Example retrieval: ```sql SELECT content FROM artifacts WHERE token = 'ARTIFACT:PLAN(SCOPE:scope_001)'; ``` ### 2.2 The Pipeline Architecture ```mermaid flowchart TD subgraph PIPE["STATELESS SOFTWARE ENGINEERING PIPELINE"] S1["STAGE 1: DISCOVERY

Input: User request, problem statement
Agent: Discovery Agent
Process: Structured discussion, questions, data gathering
Output: Feature requirements, non-functional requirements,
notes, goals, problems to solve, references, examples"] S2["STAGE 2: PLANNING

Input: Discovery artifacts
Agent: Planning Agent (with RT-ICA)
Process: Review goals, assess prerequisites, design solution
Output: Feature design guide with success criteria"] S3["STAGE 3: CONTEXT INTEGRATION

Input: Design guide + codebase access
Agent: Context Integration Agent
Process:
- Review plan against existing codebase
- Identify already-complete scope
- Find conflicts, contradictions, constraints
- Map existing systems, methodologies, utilities
- Add file/URL references to plan
Output: Contextualized plan with concrete references"] S4["STAGE 4: TASK DECOMPOSITION

Input: Contextualized plan
Agent: Task Decomposition Agent
Process: Create atomic tasks following TDD pattern:
1. Create interfaces
2. Write failing tests
3. Implement functionality
4. Validate via linting
5. Validate via testing
6. Repeat until passing
Output: Task file with:
- Exact constraints
- Files to modify
- Style to follow
- Methodology to use
- Language specifications
- Self-verification steps
- Definition of done"] S5["STAGE 5: EXECUTION

Input: Task file (contains ALL context needed)
Agent: Execution Agent (FRESH SESSION)
Process:
- Receive task file as complete prompt
- Execute exactly as specified
- Follow embedded self-verification steps
- No need to recall or infer - all answers provided
Output: Implemented code + verification results"] S6["STAGE 6: FORENSIC REVIEW

Input: Execution results + original plan
Agent: Forensic Review Agent
Process:
- Validate task completion against plan
- Review + critique + fact-check
- Quality assessment
- Determine: COMPLETE or NEEDS_ADDITIONAL_WORK
Output: Completion report with findings"] DECISION{COMPLETE or ISSUES?} COMPLETE["COMPLETE"] ISSUES["ISSUES"] PLANNER["Planner Agent
(creates new tasks)"] ORCH["Orchestrator
(dispatches workers)"] S7["STAGE 7: FINAL VERIFICATION

Input: All completed tasks + original goals
Agent: Final Verification Agent
Process:
- Verify feature achieves original goal
- Validate acceptance criteria
- Confirm definition of done
Output: Feature completion certification"] S1 --> S2 --> S3 --> S4 --> S5 --> S6 --> DECISION DECISION -->|COMPLETE| COMPLETE --> S7 DECISION -->|ISSUES| ISSUES --> PLANNER --> ORCH --> S5 end ``` ### 2.3 Artifact Flow ```mermaid flowchart TD REQ["User Request"] DISC["ARTIFACT:DISCOVERY(SCOPE:...)
Feature requirements, NFRs, goals, references
(e.g. discovery-output.md)"] DESIGN["ARTIFACT:PLAN(SCOPE:...)
Solution design, success criteria, approach
(e.g. design-guide.md)"] CTX["ARTIFACT:PLAN(SCOPE:...)
Plan + existing code references, conflicts resolved,
utilities identified, file paths mapped
(e.g. contextualized-plan.md)"] TASK["ARTIFACT:TASK(TASK:...)
Atomic task with ALL context embedded:
- Constraints, files, style, methodology
- Self-verification steps, DoD
(e.g. task-{N}-{name}.md)"] EXEC["ARTIFACT:EXECUTION(TASK:...)
Implementation results, verification output
(e.g. execution-results-{N}.md)"] REVIEW["ARTIFACT:REVIEW(TASK:...)
Findings, issues, completion status
(e.g. review-report-{N}.md)"] CERT["ARTIFACT:VERIFICATION(SCOPE:...)
Final certification against original goals
(e.g. feature-certification.md)"] REQ --> DISC --> DESIGN --> CTX --> TASK --> EXEC --> REVIEW --> CERT ``` --- ## Part 3: Agent Specifications ### 3.1 Discovery Agent **Purpose**: Gather complete information through structured discussion with user **Input**: - User's initial request or problem statement **Process**: 1. Identify the problem domain 2. Ask clarifying questions about: - Who are the users? - What problem are we solving? - What does success look like? - What are the constraints? - What already exists? 3. Gather references and examples 4. Document non-functional requirements 5. Capture explicit goals and anti-goals **Output**: `ARTIFACT:DISCOVERY(SCOPE:...)` (e.g. `discovery-output.md`) ```markdown ## Feature: {name} ### Problem Statement {what problem we're solving} ### Users {who will use this} ### Goals - {goal 1} - {goal 2} ### Anti-Goals (Out of Scope) - {explicitly not doing this} ### Functional Requirements 1. {requirement} 2. {requirement} ### Non-Functional Requirements - Performance: {criteria} - Security: {criteria} - Compatibility: {criteria} ### References - {link or file path} - {example from similar system} ### Open Questions (Resolved) - Q: {question} A: {answer from user} ### Notes {additional context captured during discussion} ``` **Success Criteria**: User confirms the discovery document accurately captures their intent. --- ### 3.2 Planning Agent **Purpose**: Transform discovery into actionable design with verified prerequisites **Input**: - `ARTIFACT:DISCOVERY(SCOPE:...)` (e.g. `discovery-output.md`) **Process**: 1. **RT-ICA Assessment**: - List all prerequisites for success - Mark each: AVAILABLE | DERIVABLE | MISSING - If MISSING: BLOCK and request information - If all AVAILABLE/DERIVABLE: PROCEED 2. **Solution Design**: - Define approach - Identify components needed - Specify success criteria - Define acceptance tests 3. **Risk Assessment**: - Technical risks - Dependency risks - Knowledge gaps **Output**: `ARTIFACT:PLAN(SCOPE:...)` (e.g. `design-guide.md`) ```markdown ## Feature Design: {name} ### RT-ICA Assessment | Prerequisite | Status | Source | |--------------|--------|--------| | {prereq} | AVAILABLE | {where it comes from} | Decision: APPROVED / BLOCKED ### Approach {high-level solution description} ### Components 1. {component}: {purpose} 2. {component}: {purpose} ### Success Criteria - [ ] {measurable criterion} - [ ] {measurable criterion} ### Acceptance Tests - Given {context}, When {action}, Then {outcome} ### Risks | Risk | Mitigation | |------|------------| | {risk} | {mitigation} | ### Dependencies - {external dependency} - {internal dependency} ``` **Success Criteria**: All prerequisites verified, no MISSING items, design addresses all requirements. --- ### 3.3 Context Integration Agent **Purpose**: Ground the design in actual codebase reality **Input**: - `ARTIFACT:PLAN(SCOPE:...)` (e.g. `design-guide.md`) - Access to codebase **Process**: 1. **Scope Analysis**: - Identify what already exists - Mark scope items as: NEW | MODIFY | COMPLETE 2. **Conflict Detection**: - Find contradictions with existing patterns - Identify technical constraints - Note architectural conflicts 3. **Resource Mapping**: - Existing utilities to reuse - Existing patterns to follow - File paths for all references 4. **Plan Update**: - Add concrete file references - Note existing implementations - Document integration points **Output**: `ARTIFACT:PLAN(SCOPE:...)` (e.g. `contextualized-plan.md`) ```markdown ## Contextualized Plan: {name} ### Scope Status | Item | Status | Notes | |------|--------|-------| | {item} | NEW | {notes} | | {item} | MODIFY | Existing: {file:line} | | {item} | COMPLETE | Already at {file:line} | ### Conflicts Resolved | Conflict | Resolution | |----------|------------| | {conflict} | {how resolved} | ### Technical Constraints - {constraint}: {implication} ### Existing Resources to Use | Resource | Location | Purpose | |----------|----------|---------| | {utility} | {file:line} | {why use it} | ### Integration Points | System | Interface | File | |--------|-----------|------| | {system} | {how to integrate} | {file path} | ### Updated Design {design with concrete references} ### File Manifest | File | Action | Purpose | |------|--------|---------| | {path} | CREATE | {purpose} | | {path} | MODIFY | {what changes} | ``` **Success Criteria**: All design elements mapped to concrete files, no unresolved conflicts, existing resources identified. --- ### 3.4 Task Decomposition Agent **Purpose**: Create atomic, self-contained task files **Input**: - `ARTIFACT:PLAN(SCOPE:...)` (e.g. `contextualized-plan.md`) **Process**: 1. **Decompose into Atomic Tasks**: - Each task: 15-60 minutes of work - Single responsibility per task - Clear input/output 2. **Order by TDD Pattern**: - Interface tasks first - Test tasks second - Implementation tasks third - Integration tasks last 3. **Embed All Context**: - No task requires recall - All answers in the task file - Complete methodology specified **Output**: `ARTIFACT:TASK(TASK:...)` for each task (e.g. `task-{N}-{name}.md`) ```markdown ## Task {N}: {name} ### Context {everything the execution agent needs to know} ### Constraints - Language: {language and version} - Style: {style guide reference} - Patterns: {patterns to follow} ### Files to Modify | File | Action | Reference | |------|--------|-----------| | {path} | CREATE/MODIFY | {ARTIFACT:PLAN(SCOPE:...) section} | ### Methodology 1. {step with specific action} 2. {step with specific action} ### Self-Verification Steps 1. [ ] {verification step} 2. [ ] {verification step} 3. [ ] {verification step} ### Definition of Done - [ ] {criterion} - [ ] {criterion} - [ ] All self-verification steps pass ### Dependencies - Requires: {task-N-1} complete - Blocks: {task-N+1} ### References - Design: ARTIFACT:PLAN(SCOPE:...)#{section} - Pattern: {file:line} - Example: {file:line} ``` **Success Criteria**: Each task is self-contained, follows TDD order, includes all context needed for execution. --- ### 3.5 Execution Agent **Purpose**: Execute a single task with embedded verification **Input**: - Single `ARTIFACT:TASK(TASK:...)` (AS THE COMPLETE PROMPT) (e.g. `task-{N}-{name}.md`) **Process**: 1. Read task file (this IS the context) 2. Execute methodology steps exactly 3. Perform self-verification steps 4. Report results **Key Properties**: - **Fresh session**: No accumulated context - **No recall needed**: All answers in task file - **Embedded verification**: Cannot skip methodology - **Single responsibility**: One task only **Output**: Implementation + `ARTIFACT:EXECUTION(TASK:...)` (e.g. `execution-results-{N}.md`) ```markdown ## Execution Results: Task {N} ### Status: COMPLETE / BLOCKED ### Implementation Summary {what was done} ### Self-Verification Results 1. [x] {step}: PASS 2. [x] {step}: PASS 3. [ ] {step}: FAIL - {reason} ### Definition of Done - [x] {criterion}: verified by {evidence} - [ ] {criterion}: not met because {reason} ### Files Changed | File | Changes | |------|---------| | {path} | {summary} | ### Blockers (if any) - {blocker}: {what's needed} ### Notes {observations during execution} ``` **Success Criteria**: Task completed per specification OR explicit blockers identified. --- ### 3.6 Forensic Review Agent **Purpose**: Independent verification that task was completed correctly **Input**: - `ARTIFACT:EXECUTION(TASK:...)` (e.g. `execution-results-{N}.md`) - `ARTIFACT:TASK(TASK:...)` (e.g. `task-{N}-{name}.md`) - `ARTIFACT:PLAN(SCOPE:...)` (e.g. `contextualized-plan.md`) **Process**: 1. **Completion Verification**: - Compare results to task requirements - Verify all DoD criteria met 2. **Quality Assessment**: - Code review against standards - Pattern compliance check - Integration verification 3. **Fact-Check**: - Verify claims in execution results - Confirm files changed as stated - Validate test results 4. **Determination**: - COMPLETE: All criteria met - NEEDS_WORK: Specific issues identified **Output**: `ARTIFACT:REVIEW(TASK:...)` (e.g. `review-report-{N}.md`) ```markdown ## Review Report: Task {N} ### Verdict: COMPLETE / NEEDS_WORK ### Completion Assessment | Criterion | Status | Evidence | |-----------|--------|----------| | {DoD item} | PASS/FAIL | {evidence} | ### Quality Assessment | Aspect | Score | Notes | |--------|-------|-------| | Code standards | {1-5} | {notes} | | Pattern compliance | {1-5} | {notes} | | Test coverage | {1-5} | {notes} | ### Fact-Check Results | Claim | Verified | Notes | |-------|----------|-------| | {claim from execution results} | YES/NO | {notes} | ### Issues Found 1. {issue}: {details} 2. {issue}: {details} ### Recommendations - {recommendation for fix} - {recommendation for improvement} ### Follow-up Tasks Needed - [ ] {new task if NEEDS_WORK} ``` **Success Criteria**: Independent verification complete, clear verdict with evidence. --- ### 3.7 Planner Agent (Iteration) **Purpose**: Create follow-up tasks from review findings **Input**: - `ARTIFACT:REVIEW(TASK:...)` with NEEDS_WORK verdict (e.g. `review-report-{N}.md`) **Process**: 1. Analyze issues found 2. Create new task files to address each issue 3. Update task dependency graph **Output**: Additional `ARTIFACT:TASK(TASK:...)` entries (e.g. `task-{N+1}-{name}.md`) --- ### 3.8 Orchestrator **Purpose**: Coordinate execution flow across all agents **Responsibilities**: - Track task status - Dispatch execution agents - Route review results - Determine when all tasks complete - Trigger final verification **Key Property**: **Thin orchestrator** - reads status, dispatches agents, does not do work itself. --- ### 3.9 Final Verification Agent **Purpose**: Verify complete feature against original goals **Input**: - `ARTIFACT:DISCOVERY(SCOPE:...)` (original goals) (e.g. `discovery-output.md`) - All `ARTIFACT:REVIEW(TASK:...)` artifacts (e.g. `review-report-{N}.md`) - `ARTIFACT:PLAN(SCOPE:...)` (e.g. `contextualized-plan.md`) **Process**: 1. **Goal Verification**: - Each original goal → evidence of completion 2. **Acceptance Criteria**: - Each criterion → test result 3. **Definition of Done**: - Feature-level DoD → verification **Output**: `ARTIFACT:VERIFICATION(SCOPE:...)` (e.g. `feature-certification.md`) ```markdown ## Feature Certification: {name} ### Status: CERTIFIED / NOT_CERTIFIED ### Goal Achievement | Goal | Status | Evidence | |------|--------|----------| | {goal from discovery} | ACHIEVED | {evidence} | ### Acceptance Criteria | Criterion | Status | Test | |-----------|--------|------| | {criterion} | PASS | {test result} | ### Definition of Done | Item | Status | |------|--------| | All tasks complete | YES | | All reviews pass | YES | | Integration verified | YES | | Documentation updated | YES | ### Summary {feature is ready for use / issues remaining} ``` --- ## Part 4: Theoretical Foundations ### 4.1 Mapping to Formal Methods | Framework Concept | Formal Method | Description | | ----------------------- | ------------------------------- | ------------------------------------ | | RT-ICA assessment | **Precondition verification** | Verify inputs before execution | | Task DoD | **Postcondition specification** | Define what must be true after | | Self-verification steps | **Invariant checking** | Maintain properties during execution | | Forensic review | **Independent verification** | Separate verifier from implementer | | Artifact handoffs | **Design by Contract** | Explicit interfaces between stages | ### 4.2 Mapping to Systems Engineering | Framework Concept | Systems Engineering | Description | | -------------------- | ---------------------------- | --------------------------------- | | Discovery → Planning | **Requirements Engineering** | Capture and validate requirements | | Context Integration | **Architecture Analysis** | Fit solution to existing system | | Task Decomposition | **Work Breakdown Structure** | Atomic work packages | | Execution + Review | **V-Model left/right side** | Build and verify | | Final Verification | **System Validation** | Confirm system meets needs | ### 4.3 Mapping to Software Patterns | Framework Concept | Software Pattern | Description | | ----------------- | ------------------------ | ------------------------------------ | | Stateless agents | **Microservices** | Independent, single-purpose services | | Artifact passing | **Message Queue** | Decoupled communication | | Orchestrator | **Saga Pattern** | Coordinate distributed transactions | | Fresh context | **Serverless Functions** | Stateless, event-triggered | | Forensic review | **Circuit Breaker** | Fail-safe verification | ### 4.4 Mapping to Manufacturing | Framework Concept | Manufacturing | Description | | -------------------------- | ------------------- | -------------------------------- | | Pipeline stages | **Assembly Line** | Sequential, specialized stations | | Verification at boundaries | **Quality Gates** | Inspect before passing | | Task files | **Work Orders** | Complete instructions for worker | | Forensic review | **Quality Control** | Independent inspection | | Recursive fixes | **Rework Station** | Fix defects, return to line | --- ## Part 5: Why This Works ### 5.1 Eliminates Claude's Failure Modes | Failure Mode | How Framework Prevents | | ------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Unsupported fabrication | Grounding: require evidence (artifacts / sources) and permit abstention when evidence is missing | | Long-context degradation | Bound context per agent; avoid “everything in one prompt”; keep relevant context small and structured ([Amazon Science](https://www.amazon.science/publications/context-length-alone-hurts-llm-performance-despite-perfect-retrieval), [arXiv:2307.03172](https://arxiv.org/abs/2307.03172)) | | Methodology skipping | Methodology IS the prompt - cannot skip | | Shortcut-taking | Verification embedded (prefer external checks) - shortcuts caught | | Goal displacement | Forensic review validates against original goals | | Self-confirmation bias | Independent verification agent; do not rely on self-critique alone | ### 5.2 Structural Enforcement vs Behavioral Instruction | Behavioral (Fails) | Structural (Works) | | ------------------------------- | -------------------------------- | | "Please follow the methodology" | Methodology is the task file | | "Verify your work" | Separate verification agent | | "Don't use training data" | Provide all needed data | | "Block if missing info" | RT-ICA gate blocks automatically | | "Don't take shortcuts" | Review catches shortcuts | ### 5.3 The Key Insight **Claude is a stateless function, not a stateful agent.** Treat it like a pure function: - Input: Complete context (task file) - Output: Verified result - No side effects: Fresh context each time - No memory: Everything externalized to files --- ## Part 6: Implementation Roadmap ### Phase 1: Core Infrastructure 1. **Artifact schemas**: Define markdown templates for each artifact type 2. **Agent definitions**: Create agent files for each role 3. **Orchestrator command**: `/sse:start` to begin workflow 4. **Status tracking**: `ARTIFACT:STATE(SCOPE:...)` for pipeline position (e.g. `STATE.md`) ### Phase 2: Stage Implementation 1. **Discovery stage**: `/sse:discover` command + agent 2. **Planning stage**: `/sse:plan` command + RT-ICA integration 3. **Context stage**: `/sse:contextualize` command + agent 4. **Decomposition stage**: `/sse:decompose` command + agent ### Phase 3: Execution Loop 1. **Execution stage**: `/sse:execute` command + fresh agent spawning 2. **Review stage**: `/sse:review` command + for …(truncated)