theslopmachine 0.4.2 → 0.4.5

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.
 
@@ -41,6 +41,10 @@ For Dockerized web backend/fullstack projects:
 - `./run_tests.sh` must run the broad full-test path through Docker
 - local non-Docker tests should still exist for normal development work
 - final broad verification should use the Dockerized `./run_tests.sh` path, not only local test commands
+- keep Compose isolation safe for shared machines: no unnecessary `container_name`, unique `COMPOSE_PROJECT_NAME`, and Compose-scoped image/network/volume naming
+- expose only the primary app-facing port to host by default, bind it to `127.0.0.1`, and keep databases/cache/internal services off host ports unless truly required
+- prefer random host-port assignment by default so parallel local projects do not collide; if a fixed host port is truly required, support override plus free-port fallback in the runtime or test wrapper
+- add healthchecks and wait for service readiness before tests or dependent startup steps proceed
 
 When `docker compose up --build` is not the runtime contract, provide `./run_app.sh` as the single primary runtime wrapper.
 
@@ -74,6 +78,8 @@ Selected-stack defaults:
 - Do not rely on `.env`, `.env.local`, `.env.example`, or similar files for project startup.
 - Do not hardcode secrets.
 - If runtime env-file format is required, generate it ephemerally and do not commit or package it.
+- If Dockerized dev/test startup or tests require credentials, provide deterministic non-secret local-only default values through Docker runtime configuration so `docker compose up --build` and `./run_tests.sh` do not fail on missing credentials.
+- Keep those Dockerized dev/test default credentials out of Dockerfile image layers.
 
 Selected-stack secret/config defaults:
 

package/assets/slopmachine/utils/strip_session_parent.py

@@ -2,10 +2,32 @@
 
 import argparse
 import json
+import re
 from pathlib import Path
 from typing import Any
 
 
+SUBAGENT_TITLE_SUFFIX = re.compile(r"\s+\(@[^)]*subagent\)\s*$")
+
+
+def clean_title(title: Any) -> Any:
+    if not isinstance(title, str):
+        return title
+    return SUBAGENT_TITLE_SUFFIX.sub("", title)
+
+
+def clean_message_info(info: Any) -> Any:
+    if not isinstance(info, dict):
+        return info
+
+    cleaned = dict(info)
+    tools = cleaned.get("tools")
+    if isinstance(tools, dict) and tools and all(value is False for value in tools.values()):
+        cleaned.pop("tools", None)
+
+    return cleaned
+
+
 def strip_parent_id(data: Any) -> Any:
     if not isinstance(data, dict):
         raise ValueError("Expected top-level JSON object")
@@ -20,13 +42,30 @@ def strip_parent_id(data: Any) -> Any:
     # Remove only the session-level parent marker. Message-level parentIDs
     # are preserved so the conversation structure remains intact.
     cleaned_info.pop("parentID", None)
+    cleaned_info.pop("permission", None)
+    cleaned_info["title"] = clean_title(cleaned_info.get("title"))
     cleaned["info"] = cleaned_info
+
+    messages = cleaned.get("messages")
+    if isinstance(messages, list):
+        cleaned_messages = []
+        for message in messages:
+            if not isinstance(message, dict):
+                cleaned_messages.append(message)
+                continue
+
+            cleaned_message = dict(message)
+            cleaned_message["info"] = clean_message_info(message.get("info"))
+            cleaned_messages.append(cleaned_message)
+
+        cleaned["messages"] = cleaned_messages
+
     return cleaned
 
 
 def parse_args() -> argparse.Namespace:
     parser = argparse.ArgumentParser(
-        description="Remove the top-level parentID from an OpenCode session export."
+        description="Remove subagent-only top-level metadata from an OpenCode session export."
     )
     parser.add_argument("input", type=Path, help="Path to the source session JSON file")
     parser.add_argument(

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "theslopmachine",
-  "version": "0.4.2",
+  "version": "0.4.5",
   "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.5";
+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",
   },
-}
+};