theslopmachine 0.4.2 → 0.4.3

package/README.md

@@ -37,7 +37,7 @@ The current engine is the lighter workflow line:
 - smaller always-loaded owner shell
 - smaller developer rulebook
 - richer phase-specific skills loaded when needed
-- bounded 2/3 developer-session model
+- bounded 2-session developer-session model
 - `beads_rust` bootstrap path
 
 ## Requirements
@@ -66,13 +66,13 @@ npm pack
 This produces a tarball such as:
 
 ```bash
-theslopmachine-0.4.0.tgz
+theslopmachine-0.4.3.tgz
 ```
 
 You can then install it globally with:
 
 ```bash
-npm install -g ./theslopmachine-0.4.0.tgz
+npm install -g ./theslopmachine-0.4.3.tgz
 ```
 
 For local development instead of global install:
@@ -143,6 +143,7 @@ The expected high-level lifecycle is:
 8. final human decision
 9. remediation when needed
 10. submission packaging
+11. retrospective
 
 ## How It Is Intended To Operate
 
@@ -154,7 +155,7 @@ That means:
 - planning, scaffold, development, verification, hardening, remediation, and packaging load detailed skills only when needed
 - early and late phases do not carry each other's full instruction payloads all the time
 
-The v2 workflow also expects:
+The current workflow also expects:
 
 - targeted reads over broad rereads
 - local and narrow verification during ordinary iteration
@@ -174,6 +175,70 @@ Examples:
 - web backend/fullstack: `docker compose up --build` and `./run_tests.sh`
 - mobile or desktop when Docker runtime is not the direct run path: `./run_app.sh` and `./run_tests.sh`
 
+## What It Does Well
+
+- keeps the owner shell strict without carrying a giant monolith prompt
+- loads detailed phase and activity skills only when they are actually needed
+- uses a bounded 2-session model to reduce long-run context drag
+- pushes prompt-fit, security, testing, and engineering-quality concerns earlier into planning and hardening
+- standardizes runtime and broad-test expectations with `docker compose up --build` or `./run_app.sh` plus `./run_tests.sh`
+- preserves strong packaging/report discipline with canonical files in `~/slopmachine/`
+
+## Installed Assets
+
+The package installs:
+
+- owner and developer agents
+- phase and activity skills
+- canonical evaluation and report templates in `~/slopmachine/`
+- workflow bootstrap helper
+- repo rulebook template
+- session export utilities
+
+Canonical files in `~/slopmachine/`:
+
+- `backend-evaluation-prompt.md`
+- `frontend-evaluation-prompt.md`
+- `document-completeness.md`
+- `engineering-results.md`
+- `implementation-comparison.md`
+- `quality-document.md`
+- `retrospectives/`
+
+## Dependencies And Assumptions
+
+- Node.js 18+ is required for the package CLI itself
+- OpenCode must already be available on the machine
+- git must be available
+- `beads_rust` / `br` is installed or verified by `slopmachine setup`
+
+Generated projects follow the original prompt and the existing repository first.
+
+Default runtime/test wrapper expectations:
+
+- Dockerized web backend/fullstack: `docker compose up --build` and `./run_tests.sh`
+- non-web or non-Docker runtime cases: `./run_app.sh` and `./run_tests.sh`
+
+`./run_tests.sh` is always the broad test wrapper.
+
+## Command Summary
+
+Package CLI:
+
+- `slopmachine setup`
+- `slopmachine init`
+- `slopmachine init -o`
+
+Package validation:
+
+- `npm run check`
+- `npm pack`
+
+Generated project conventions:
+
+- `docker compose up --build` or `./run_app.sh`
+- `./run_tests.sh`
+
 ## Files And Locations
 
 Main install locations:

package/RELEASE.md

@@ -41,13 +41,13 @@ npm pack
 This should produce a tarball such as:
 
 ```bash
-theslopmachine-0.4.0.tgz
+theslopmachine-0.4.3.tgz
 ```
 
 ## Inspect package contents
 
 ```bash
-tar -tzf theslopmachine-0.4.0.tgz
+tar -tzf theslopmachine-0.4.3.tgz
 ```
 
 Check that the tarball includes:

package/assets/agents/slopmachine.md

@@ -67,7 +67,7 @@ Agent-integrity rule:
 
 ## Optimization Goal
 
-The main v2 target is:
+The main target is:
 
 - less token waste
 - less elapsed time
@@ -174,18 +174,17 @@ Phase rules:
 
 ## Developer Session Model
 
-Use up to three bounded developer sessions:
+Use up to two bounded developer sessions:
 
-1. build session: planning, scaffold, development
-2. stabilization session: integrated verification and hardening, only if needed
-3. remediation session: evaluation-response remediation, only if needed
+1. develop session: planning, scaffold, development
+2. bugfix session: integrated verification, hardening, and remediation, only if needed
 
 Use `developer-session-lifecycle` for startup, resume detection, session consistency checks, and recovery.
 Use `session-rollover` only for planned transitions between those bounded developer sessions.
 
 Do not launch the developer during `P0` or `P1`.
 
-When the first build developer session begins in `P2`, start it in this exact order:
+When the first develop developer session begins in `P2`, start it in this exact order:
 
 1. send `lets plan this <original-prompt>`
 2. wait for the developer's first reply

package/assets/skills/developer-session-lifecycle/SKILL.md

@@ -59,7 +59,7 @@ Optional startup inputs may include:
 6. wait only for the initial clarification approval before development starts
 7. ensure the parent project root has the required working structure, especially `../sessions/` and `../docs/`
 8. initialize the bounded developer-session slots
-9. start the build developer session only after `P2` is ready to begin
+9. start the develop developer session only after `P2` is ready to begin
 10. send this exact first planning opener as the first message in that session: `lets plan this <original-prompt>`
 11. wait for the developer's first exchange
 12. send the approved clarification prompt as the second owner message in that same session
@@ -69,7 +69,7 @@ Optional startup inputs may include:
 
 The first bounded developer session must begin in this exact order:
 
-1. owner starts the build developer session
+1. owner starts the develop developer session
 2. owner sends: `lets plan this <original-prompt>`
 3. developer responds
 4. owner sends the approved clarification prompt
@@ -138,11 +138,10 @@ Required project metadata fields in `../metadata.json` when relevant:
 
 ## Bounded session model
 
-Track up to three planned developer sessions:
+Track up to two planned developer sessions:
 
-1. build
-2. stabilization
-3. remediation
+1. develop
+2. bugfix
 
 Later session slots may remain unused if the workflow never needs them.
 

package/assets/skills/planning-guidance/SKILL.md

@@ -110,7 +110,7 @@ Selected-stack defaults:
 - for each major module, define how it integrates with existing modules and which shared contracts it must follow consistently
 - define verification plans that include cross-module scenarios and seam checks, not just isolated feature checks
 - surface real unresolved risks honestly
-- keep the plan aligned with current policy: owner-managed external docs, no `.env` files, junior-friendly repo-local README, and the v2 verification cadence
+- keep the plan aligned with current policy: owner-managed external docs, no `.env` files, junior-friendly repo-local README, and the current verification cadence
 
 ## Exit target
 

package/assets/skills/session-rollover/SKILL.md

@@ -9,8 +9,7 @@ Use this skill only when intentionally moving from one planned developer session
 
 ## Typical uses
 
-- build session -> stabilization session
-- stabilization session -> remediation session
+- develop session -> bugfix session
 
 ## Rules
 

package/assets/skills/submission-packaging/SKILL.md

@@ -104,7 +104,7 @@ The final submission layout in the parent project root must be:
 - relocate screenshots and proof materials relevant to runtime behavior and major flows into parent-root `../submission/`
 - preserve parent-root `../sessions/` as the session artifact directory for converted workflow session exports
 - export all tracked workflow sessions before generating the final submission documents
-- after the session exports are complete, use the last evaluation session recorded in metadata when generating the final submission report content so the report answers can come from cached evaluation context instead of rebuilding that context from scratch
+- after the session exports are complete, the owner should answer the final submission-document questions based on the recent review responses gathered across evaluation reports, remediation results, verification notes, and packaging checks
 
 ## Session export sequence
 
@@ -120,8 +120,8 @@ For each tracked session:
 
 Naming rule for converted files under `../sessions/`:
 
-- development-phase sessions become `develop-N.json`
-- hardening or remediation sessions become `bugfix-N.json`
+- the develop session becomes `develop-N.json`
+- the bugfix session becomes `bugfix-N.json`
 
 After those steps:
 
@@ -135,13 +135,13 @@ After those steps:
 
 After all session exports are complete:
 
-1. recover the last evaluation session id from metadata
-2. use that last evaluation session to answer the final submission-document questions from its cached context
-3. generate the required final submission documents from that evaluation context plus the canonical `~/slopmachine/` reference files
+1. gather the recent review responses from evaluation reports, accepted triage notes, remediation outcomes, verification notes, and packaging checks
+2. answer the final submission-document questions from that gathered review evidence
+3. generate the required final submission documents from that gathered review evidence plus the canonical `~/slopmachine/` reference files
 
 Do not start generating the final submission documents before the session exports are complete.
-Do not create a new evaluation session for final report generation if the last evaluation session is still available.
-If the last evaluation session id is missing or unusable, stop and repair metadata/session recovery before continuing packaging.
+Do not rely on one single cached evaluation session as the only source for final submission-document answers.
+If the gathered review evidence is incomplete, stop and repair the missing evidence before continuing packaging.
 
 ## Required file moves
 
@@ -171,8 +171,8 @@ If the last evaluation session id is missing or unusable, stop and repair metada
 - confirm required screenshots have been relocated into parent-root `../submission/`
 - confirm parent-root metadata fields are populated correctly
 - confirm session export naming rules are followed under `../sessions/`:
-  - `develop-N.json` for development-phase sessions
-  - `bugfix-N.json` for hardening/remediation sessions
+  - `develop-N.json` for the develop session
+  - `bugfix-N.json` for the bugfix session
 
 ## Submission artifact and response contract
 

package/assets/skills/verification-gates/SKILL.md

@@ -77,7 +77,7 @@ Use this skill after development begins whenever you are reviewing work, decidin
 - a broad gate is an owner-run integrated verification boundary, not every ordinary phase change
 - a phase change alone does not automatically require a broad gate unless that phase exit explicitly calls for one
 - a broad gate normally means some combination of full clean runtime proof, `./run_tests.sh`, and platform-appropriate UI/E2E evidence when UI-bearing flows exist
-- in v2, the workflow target is at most 3 broad owner-run verification moments across the whole cycle
+- the workflow target is at most 3 broad owner-run verification moments across the whole cycle
 - ordinary planning, ordinary slice acceptance, and routine in-phase verification are not broad gates by default and should rely on targeted local verification unless the risk profile says otherwise
 
 For Dockerized web backend/fullstack projects, the default Docker cadence is:

package/assets/slopmachine/document-completeness.md

@@ -1,45 +1,59 @@
-## 5.1 Document Completeness
+## Delivery Completeness Template
+
+Use this file as the structure reference for the delivery-completeness and hard-threshold submission outputs.
+
+Do not copy sample-project content into the final document.
+Replace every placeholder with evidence from the current delivered project.
+
+## Document completeness
 
 | Document Type | File Path | Completeness | Description |
 | :---- | :---- | :---- | :---- |
-| **User Instructions** | README.md | ✅ Complete | Includes functional features, installation steps, and usage guides |
-| **Testing Instructions** | TESTING.md | ✅ Complete | Test environment isolation and execution methods |
-| **Data Persistence Instructions** | DATA\_PERSISTENCE.md | ✅ Complete | Docker volume mounting and data protection |
+| **User Instructions** | `<path>` | `<Complete/Partial/Missing>` | `<what is present and whether it is enough>` |
+| **Testing Instructions** | `<path>` | `<Complete/Partial/Missing>` | `<how local and broad test paths are documented>` |
+| **Runtime/Deployment Instructions** | `<path>` | `<Complete/Partial/Missing>` | `<how runtime startup is documented>` |
+| **Other Required Project Docs** | `<path>` | `<Complete/Partial/Missing>` | `<other prompt-required or delivery-required docs>` |
 
-5.2 Code Completeness
+## Code completeness
 
-| Module | Implementation Status | Description |
+| Module / Area | Implementation Status | Description |
 | :---- | :---- | :---- |
-| **Configuration Management** | ✅ Complete | complaint\_system/settings.py |
-| **URL Routing** | ✅ Complete | complaint\_system/urls.py, main/urls.py |
-| **Data Models** | ✅ Complete | main/models.py (FoodVote, Suggestion) |
-| **View Functions** | ✅ Complete | main/views.py (5 view functions) |
-| **Backend Management** | ✅ Complete | main/admin.py |
-| **Template Files** | ✅ Complete | main/templates/ (4 templates) |
-| **Test Suite** | ✅ Complete | tests/ (41 test cases) |
-| **Dependency Config** | ✅ Complete | requirements.txt |
-| **Docker Config** | ✅ Complete | Dockerfile, docker-compose.yml |
-| **Startup Script** | ✅ Complete | docker-entrypoint.sh |
-| **Test Data** | ✅ Complete | add\_test\_data.py |
-
-5.3 Deployment Completeness
-
-| Deployment Method | Implementation Status | Description |
+| **Core runtime** | `<Complete/Partial/Missing>` | `<what exists>` |
+| **Primary user-facing flows** | `<Complete/Partial/Missing>` | `<what exists>` |
+| **Admin/operator flows** | `<Complete/Partial/Missing/Not Applicable>` | `<what exists>` |
+| **Persistence / state / data model** | `<Complete/Partial/Missing/Not Applicable>` | `<what exists>` |
+| **Tests** | `<Complete/Partial/Missing>` | `<what exists>` |
+| **Build / packaging / runtime config** | `<Complete/Partial/Missing>` | `<what exists>` |
+
+## Runtime and deployment completeness
+
+| Runtime Method | Implementation Status | Description |
 | :---- | :---- | :---- |
-| **Local Execution** | ✅ Complete | requirements.txt \+ python manage.py runserver |
-| **Docker Deployment** | ✅ Complete | docker compose up one-click startup |
-| **Data Persistence** | ✅ Complete | Volume mounting for media\_data and db\_data |
-| **Auto-Initialization** | ✅ Complete | Automatic database migration, admin creation, and test data addition |
+| **Primary runtime command** | `<Complete/Partial/Missing>` | `<docker compose up --build or ./run_app.sh, etc.>` |
+| **Broad test command** | `<Complete/Partial/Missing>` | `<./run_tests.sh behavior>` |
+| **Local development verification** | `<Complete/Partial/Missing>` | `<local tests/tools present for normal iteration>` |
+| **Persistence / initialization / automation** | `<Complete/Partial/Missing/Not Applicable>` | `<what happens automatically>` |
 
-5.4 Delivery Completeness Rating
+## Delivery completeness rating
 
-**Rating: 10/10**
+**Rating:** `<score or qualitative result>`
 
 **Strengths:**
 
-* **Complete Documentation**: README and other documents are comprehensive  
-* **Complete Code**: All functional modules are implemented with nothing missing  
-* **Runnability**: Supports both local execution and Docker one-click deployment  
-* **Test Coverage**: 41 test cases with a completely isolated test environment  
-* **Automation**: Docker startup automatically completes all initialization tasks
+- `<strength 1>`
+- `<strength 2>`
+- `<strength 3>`
+
+**Gaps or limits:**
+
+- `<gap 1 or 'None material'>`
+- `<gap 2 if needed>`
+
+## Hard-threshold summary inputs
+
+Explicitly answer:
 
+1. Can the delivered product actually run through its primary runtime command?
+2. Can the delivered product actually be verified through `./run_tests.sh`?
+3. Does the delivered output fully cover the core prompt requirements?
+4. Is the delivered product a real 0-to-1 delivery rather than a partial or schematic implementation?

package/assets/slopmachine/engineering-results.md

@@ -1,59 +1,63 @@
-**Engineering Details and Professionalism \- Self-Test Results**
+## Engineering Details and Professionalism Template
 
-* **Coding Standards**  
-* **Error Handling**  
-* **Input Validation and Message Prompts**  
-* **Error Handling**  
-* **File Upload Security**
+Use this file as the structure reference for the engineering-details-and-professionalism submission output.
 
-**Image Upload Configuration**
+Do not copy stack-specific example code or project-specific security claims into the final document.
+Replace every placeholder with current-project evidence.
 
-image \= models.ImageField(upload\_to='suggestions/', blank=True, null=True)
+## Core checklist
 
-**Security Features:**
+Cover these areas explicitly using project-type equivalents when the exact surface changes:
 
-* ✅ **CSRF Protection**: All POST requests require a CSRF token  
-* ✅ **XSS Protection**: Django templates automatically escape HTML  
-* ✅ **SQL Injection Protection**: Uses Django ORM with parameterized queries  
-* ✅ **Clickjacking Protection**: X-Frame-Options middleware  
-* ✅ **File Uploads**: Uses ImageField to validate image formats
+1. coding standards and consistency
+2. error handling and user-safe failures
+3. input validation
+4. logging or diagnostics
+5. security-sensitive implementation details
+6. test integrity
+7. cleanup and professionalism
 
-**Test Integrity**
+## Engineering details review
 
-**4.4.1 Test Case Coverage**
+### Coding standards
+- `<what standards/patterns are followed>`
 
-**Test Coverage:**
+### Error handling
+- `<how errors are handled and surfaced safely>`
 
-* ✅ **Model Testing**: 19 test cases (FoodVote, Suggestion, User models)  
-* ✅ **View Testing**: 14 test cases (Home page, voting, suggestion list, word cloud generation)  
-* ✅ **Integration Testing**: 8 test cases (End-to-end process, Chinese language support)  
-* ✅ **Total**: 41 test cases all passed
+### Input validation
+- `<how important inputs are validated>`
 
-**Test Isolation Mechanism:**
+### Logging / diagnostics
+- `<what logging or diagnostics exist>`
 
-* ✅ Uses in-memory database (:memory:), automatically cleared after testing  
-* ✅ Automatic transaction rollback after each test function runs  
-* ✅ Test data does not pollute the production database (db.sqlite3)  
-* ✅ Automatic data initialization scripts in startup scripts are disabled
+### Security details
+- `<security mechanisms actually present>`
 
-**Test Screenshots**
+### Test integrity
+- `<test types present, isolation model, and major coverage notes>`
 
-**Test Success Screenshots**
+### Cleanup and professionalism
+- `<absence of secrets, debug leftovers, committed dependency trees, etc.>`
 
-**Engineering Details Rating**
+## Checklist table
 
-**Strengths:**
+| Check | Status | Evidence |
+| :---- | :---- | :---- |
+| Error handling is credible | `<Pass/Partial/Fail>` | `<evidence>` |
+| Important inputs are validated | `<Pass/Partial/Fail>` | `<evidence>` |
+| Logging/diagnostics are useful | `<Pass/Partial/Fail>` | `<evidence>` |
+| No secrets/keys are committed | `<Pass/Partial/Fail>` | `<evidence>` |
+| No committed dependency directories | `<Pass/Partial/Fail>` | `<evidence>` |
+| No obvious leftover debug statements | `<Pass/Partial/Fail>` | `<evidence>` |
 
-* **Coding Standards**: Follows PEP 8, clear naming, complete Chinese comments  
-* **Error Handling**: Layered processing, user-friendly prompts, comprehensive exception capturing  
-* **Security**: Django built-in security features, CSRF/XSS/SQL injection protection  
-* **Test Integrity**: 41 test cases, completely isolated test environment  
-* **Maintainability**: Modular design, clear responsibilities, easy to extend
+## Professionalism summary
 
-**Room for Improvement:**
+**Strengths:**
 
-* Consider adding logging functionality  
-* Consider adding API documentation (e.g., using Swagger)
+- `<strength 1>`
+- `<strength 2>`
 
-Would you like me to help you draft the logging configuration or the Swagger integration mentioned in the improvement section?
+**Remaining concerns:**
 
+- `<concern 1 or 'None material'>`

package/assets/slopmachine/implementation-comparison.md

@@ -1,36 +1,43 @@
-**8.2 Actual Implementation vs. Requirements Comparison**
+## Prompt Understanding and Adaptability Template
 
-| Requirement Item | Original Requirement | Actual Implementation | Exceeding Portion |
+Use this file as the structure reference for the prompt-understanding-and-adaptability submission output.
+
+Do not copy example requirements or project-specific features into the final document.
+Replace every placeholder with current-project evidence.
+
+## Actual implementation vs requirements comparison
+
+| Requirement Item | Original Requirement | Actual Implementation | Exceeding Portion / Notes |
 | :---- | :---- | :---- | :---- |
-| **Complaint & Suggestion Function** | Basic requirement | ✅ Fully implemented | Added categories, status tracking, and administrator replies |
-| **Data Management** | Basic requirement | ✅ Fully implemented | Added Django Admin backend management |
-| **User Interaction** | Not specified | ✅ Fully implemented | Added responsive design and aesthetic interface |
-| **Innovative Features** | Not required | ✅ Exceeded implementation | "What I Want to Eat Most Tomorrow" leaderboard, voting function, and word cloud display |
-| **Image Upload** | Not required | ✅ Exceeded implementation | Supports uploading images as evidence |
-
-**8.3 Depth of Requirement Understanding**  
-The project not only met the original requirements but also deeply understood the underlying business scenarios:
-
-* **Understood the "Canteen" scenario**: Beyond just complaints and suggestions, a "What I Want to Eat Most Tomorrow" voting function was added to increase user engagement.  
-* **Understood "Management" needs**: Provided a complete backend management system supporting categorization, status tracking, and administrator replies.  
-* **Understood the value of "Visualization"**: Used word clouds to display trending issues, intuitively showing user points of concern.  
-* **Understood the importance of "User Experience"**: Responsive design, aesthetic interface, and smooth animations.  
-* **Understood the key to "Runnability"**: Docker one-click deployment, data persistence, and comprehensive testing.  
-* **Homepage Display**  
-* **Suggestion Word Cloud**  
-* **Submit Suggestion**  
-* **View Suggestions**  
-* **Status Filtering**
-
-**Admin Management Default Password**: admin / admin123
-
-* **Admin Management**  
-* **Background Color Toggle**  
-* **Add User**  
-* **Modify User Information**  
-* **User Permission Control**  
-* **Modify Suggestion**  
-* **Batch Execution**  
-* **Search**  
-* **Add Suggestion**
+| `<requirement>` | `<what the prompt asked for>` | `<what was delivered>` | `<extra or note>` |
+| `<requirement>` | `<what the prompt asked for>` | `<what was delivered>` | `<extra or note>` |
+
+## Depth of requirement understanding
+
+Explain whether the delivered project shows real understanding of:
+
+- business objectives
+- user and operator flows
+- implicit constraints
+- runnability and maintainability expectations
+- why the chosen implementation fits the actual problem
+
+Use project-specific evidence only.
+
+## Prompt-fit summary
+
+Answer explicitly:
+
+1. Did the implementation stay aligned with the actual prompt?
+2. Did it cover the core required flows completely?
+3. Did it understand the business goal rather than only surface technical tasks?
+4. Where did it exceed, refine, or interpret the prompt, and was that prompt-faithful?
+
+## Over-delivery / adaptability notes
+
+- `<meaningful improvement or adaptation>`
+- `<meaningful improvement or adaptation>`
+
+## Risks or caveats
 
+- `<any remaining prompt-fit caveat or 'None material'>`

package/assets/slopmachine/quality-document.md

@@ -1,108 +1,67 @@
-**Self-Test Results \- Engineering and Architecture Quality**  
-**Project Positioning**
+## Engineering and Architecture Quality Template
 
-This is a full-stack canteen management system, including:
+Use this file as the structure reference for the engineering-and-architecture self-assessment output.
 
-* **Frontend Display Page**: User-facing; displays "Tomorrow's Most Wanted Food List," allows submission of opinions and suggestions, and displays word clouds.  
-* **Administrator Backend**: Admin-facing; manages food voting and opinions/suggestions.
+Do not copy stack-specific or project-specific example content into the final document.
+Replace every placeholder with current-project evidence.
 
-**Technology Stack Selection**
+## Project positioning
 
-* **Backend**: Django 6.0.2 \+ Python 3.8+  
-* **Database**: SQLite3  
-* **Image Processing**: Pillow 12.1.0  
-* **Chinese Segmentation**: jieba 0.42.1  
-* **Word Cloud Generation**: wordcloud 1.9.6 \+ matplotlib 3.10.8  
-* **Testing Framework**: pytest 8.3.4 \+ pytest-django 4.9.0  
-* **Deployment**: Docker Compose one-click startup
+- **Project Type:** `<web/mobile/desktop/cli/library/etc.>`
+- **Primary problem solved:** `<short summary>`
+- **Major user or operator surfaces:**
+  - `<surface 1>`
+  - `<surface 2>`
 
-**Overall Architecture Diagram**
+## Technology stack selection
 
-*(Architecture diagram placeholder)*
+- **Primary runtime stack:** `<actual stack>`
+- **Primary language(s):** `<actual language(s)>`
+- **Persistence / data layer:** `<actual persistence>`
+- **Testing stack:** `<actual test stack>`
+- **Deployment / runtime model:** `<actual runtime model>`
 
-**Architecture Description:**
+## Architecture description
 
-* **Client Layer**: Browser access to frontend pages and backend management.  
-* **URL Routing Layer**: Receives HTTP requests and routes them to corresponding view functions.  
-* **View Layer**: Processes business logic and calls the model layer for data operations.  
-* **Model Layer**: Defines data models and interacts with the database via Django ORM.  
-* **Template Layer**: Renders HTML pages to return to the client.  
-* **Backend Management**: Management interface provided by Django Admin.  
-* **Data Layer**: SQLite3 database for data storage.
+- **High-level structure:** `<major layers/modules>`
+- **Runtime boundaries:** `<how runtime pieces fit together>`
+- **Data or state boundaries:** `<where state lives and how it flows>`
+- **Key contracts:** `<critical interfaces or shared contracts>`
 
-**Module Division (Clear Responsibilities)**
+## Module division
 
-| Module | Responsibility | File |
+| Module | Responsibility | File / Area |
 | :---- | :---- | :---- |
-| **Configuration Management** | Django settings, middleware, database configuration | complaint\_system/settings.py |
-| **URL Routing** | Request routing and dispatch | complaint\_system/urls.py, main/urls.py |
-| **Data Models** | ORM model definitions, database table structures | main/models.py |
-| **View Functions** | Business logic processing, request/response handling | main/views.py |
-| **Backend Management** | Django Admin configuration | main/admin.py |
-| **Templates** | HTML page rendering | main/templates/ |
-| **Testing** | Unit testing, integration testing | tests/ |
+| `<module>` | `<responsibility>` | `<path>` |
+| `<module>` | `<responsibility>` | `<path>` |
 
-**Request Processing Flow**
+## Architecture quality assessment
 
-*(Data flow diagram placeholder)*
+**Score / Rating:** `<score or qualitative result>`
 
-**3.2 Architecture Quality Rating**
+**Strengths:**
 
-**Score: 9.0/10**
+- `<strength 1>`
+- `<strength 2>`
+- `<strength 3>`
 
-**Pros:**
+**Areas for improvement:**
 
-* **Modular Design**: Clear responsibilities, low coupling, and easy to maintain.  
-* **Layered Architecture**: Clear levels from View Layer → Model Layer → Data Layer.  
-* **Django Best Practices**: Utilizes built-in functions such as Django ORM, Admin, and Messages.  
-* **Centralized Configuration**: All configurations are managed centrally in settings.py.  
-* **Scalability**: The database can be easily replaced with PostgreSQL or MySQL.
+- `<improvement 1 or 'None material'>`
+- `<improvement 2 if needed>`
 
-**Areas for Improvement:**
+## Maintainability review
 
-* Consider introducing a Service layer to decouple complex business logic from views.  
-* Consider using the Django REST Framework to provide API interfaces.
+Address explicitly:
 
-**3.3 Database Design**
+1. Is the structure modular and reviewable?
+2. Are cross-cutting concerns handled consistently?
+3. Are there major coupling or extension risks?
+4. Does the project look like a credible maintained system rather than a stacked prototype?
 
-**Table Structure: FoodVote (Food Voting)**
-
-| Field | Type | Description |
-| :---- | :---- | :---- |
-| id | INTEGER PK | Primary Key |
-| name | VARCHAR(100) | Food Name |
-| meal\_type | VARCHAR(20) | Meal Type (breakfast/lunch/dinner) |
-| vote\_count | INTEGER | Vote Count |
-| created\_at | DATETIME | Creation Time |
-| updated\_at | DATETIME | Update Time |
-
-**Table Structure: Suggestion (Opinions and Suggestions)**
-
-| Field | Type | Description |
-| :---- | :---- | :---- |
-| id | INTEGER PK | Primary Key |
-| title | VARCHAR(200) | Title |
-| content | TEXT | Content |
-| category | VARCHAR(20) | Category (food/service/environment/price/other) |
-| status | VARCHAR(20) | Status (pending/processing/resolved/closed) |
-| submitter\_name | VARCHAR(50) | Submitter Name (Optional) |
-| submitter\_contact | VARCHAR(100) | Contact Info (Optional) |
-| image | VARCHAR(100) | Image Path (Optional) |
-| admin\_reply | TEXT | Admin Reply (Optional) |
-| created\_at | DATETIME | Creation Time |
-| updated\_at | DATETIME | Update Time |
-
-**Index Design**
-
-* **FoodVote Table Index**: Composite index to support queries by meal type and vote count: models.Index(fields=\['meal\_type', '-vote\_count'\]).  
-* **Suggestion Table Index**:  
-  * Composite index for status and creation time: models.Index(fields=\['status', '-created\_at'\]).  
-  * Composite index for category and creation time: models.Index(fields=\['category', '-created\_at'\]).
-
-**Design Evaluation:**
-
-* ✅ Index design is reasonable and covers main query scenarios.  
-* ✅ Field types are chosen appropriately, using TextChoices enumeration types.  
-* ✅ Uses Django ORM for easy migration to other databases.  
-* ✅ Timestamp fields are automatically managed using auto\_now\_add and auto\_now.
+## Evidence to include
 
+- brief architecture explanation
+- major module map
+- any key diagrams or screenshots when useful
+- repo structure screenshot reference when used in the final generated file

package/assets/slopmachine/templates/AGENTS.md

@@ -1,4 +1,4 @@
-# Developer Rulebook v2
+# Developer Rulebook
 
 This file is the repo-local engineering rulebook for `slopmachine` projects.
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "theslopmachine",
-  "version": "0.4.2",
+  "version": "0.4.3",
   "description": "SlopMachine installer and project bootstrap CLI",
   "license": "MIT",
   "type": "module",

package/src/constants.js

@@ -1,87 +1,90 @@
-import os from 'node:os'
-import path from 'node:path'
-import { fileURLToPath } from 'node:url'
+import os from "node:os";
+import path from "node:path";
+import { fileURLToPath } from "node:url";
 
-export const PACKAGE_VERSION = '0.4.0'
-export const OPCODE_VERSION = '1.3.5'
-export const BR_VERSION = '0.1.34'
-export const PACKAGE_ROOT = path.resolve(path.dirname(fileURLToPath(import.meta.url)), '..')
+export const PACKAGE_VERSION = "0.4.3";
+export const OPCODE_VERSION = "1.3.5";
+export const BR_VERSION = "0.1.34";
+export const PACKAGE_ROOT = path.resolve(
+  path.dirname(fileURLToPath(import.meta.url)),
+  "..",
+);
 
 export function resolveHomeDir() {
-  return process.env.SLOPMACHINE_HOME || os.homedir()
+  return process.env.SLOPMACHINE_HOME || os.homedir();
 }
 
 export function buildPaths() {
-  const home = resolveHomeDir()
+  const home = resolveHomeDir();
   return {
     home,
-    slopmachineDir: path.join(home, 'slopmachine'),
-    opencodeDir: path.join(home, '.config', 'opencode'),
-    opencodeAgentsDir: path.join(home, '.config', 'opencode', 'agents'),
-    opencodeConfigPath: path.join(home, '.config', 'opencode', 'opencode.json'),
-    globalSkillsDir: path.join(home, '.agents', 'skills'),
-  }
+    slopmachineDir: path.join(home, "slopmachine"),
+    opencodeDir: path.join(home, ".config", "opencode"),
+    opencodeAgentsDir: path.join(home, ".config", "opencode", "agents"),
+    opencodeConfigPath: path.join(home, ".config", "opencode", "opencode.json"),
+    globalSkillsDir: path.join(home, ".agents", "skills"),
+  };
 }
 
 export const REQUIRED_SKILL_DIRS = [
-  'clarification-gate',
-  'developer-session-lifecycle',
-  'session-rollover',
-  'final-evaluation-orchestration',
-  'beads-operations',
-  'planning-guidance',
-  'planning-gate',
-  'scaffold-guidance',
-  'development-guidance',
-  'verification-gates',
-  'integrated-verification',
-  'hardening-gate',
-  'evaluation-triage',
-  'remediation-guidance',
-  'submission-packaging',
-  'retrospective-analysis',
-  'owner-evidence-discipline',
-  'report-output-discipline',
-  'frontend-design',
-]
+  "clarification-gate",
+  "developer-session-lifecycle",
+  "session-rollover",
+  "final-evaluation-orchestration",
+  "beads-operations",
+  "planning-guidance",
+  "planning-gate",
+  "scaffold-guidance",
+  "development-guidance",
+  "verification-gates",
+  "integrated-verification",
+  "hardening-gate",
+  "evaluation-triage",
+  "remediation-guidance",
+  "submission-packaging",
+  "retrospective-analysis",
+  "owner-evidence-discipline",
+  "report-output-discipline",
+  "frontend-design",
+];
 
 export const REQUIRED_SLOPMACHINE_FILES = [
-  'backend-evaluation-prompt.md',
-  'frontend-evaluation-prompt.md',
-  'document-completeness.md',
-  'quality-document.md',
-  'engineering-results.md',
-  'implementation-comparison.md',
-  'workflow-init.js',
-  'templates/AGENTS.md',
-  'utils/strip_session_parent.py',
-  'utils/convert_ai_session.py',
-]
+  "backend-evaluation-prompt.md",
+  "frontend-evaluation-prompt.md",
+  "document-completeness.md",
+  "quality-document.md",
+  "engineering-results.md",
+  "implementation-comparison.md",
+  "workflow-init.js",
+  "templates/AGENTS.md",
+  "utils/strip_session_parent.py",
+  "utils/convert_ai_session.py",
+];
 
 export const MCP_ENTRIES = {
-  'chrome-devtools': {
-    type: 'local',
-    command: ['npx', '-y', 'chrome-devtools-mcp@latest'],
+  "chrome-devtools": {
+    type: "local",
+    command: ["npx", "-y", "chrome-devtools-mcp@latest"],
   },
   context7: {
     enabled: true,
-    type: 'remote',
-    url: 'https://mcp.context7.com/mcp',
+    type: "remote",
+    url: "https://mcp.context7.com/mcp",
     headers: {
-      CONTEXT7_API_KEY: '',
+      CONTEXT7_API_KEY: "",
     },
   },
   exa: {
     enabled: true,
-    type: 'remote',
-    url: 'https://mcp.exa.ai/mcp',
+    type: "remote",
+    url: "https://mcp.exa.ai/mcp",
     headers: {
-      EXA_API_KEY: '',
+      EXA_API_KEY: "",
     },
   },
   shadcn: {
-    command: ['npx', 'shadcn@latest', 'mcp'],
+    command: ["npx", "shadcn@latest", "mcp"],
     enabled: false,
-    type: 'local',
+    type: "local",
   },
-}
+};