devloom 1.0.0 → 1.2.0

package/skills/loop/verifier.md

@@ -0,0 +1,20 @@
+---
+name: loop-verifier
+description: Verify loop tick output before it takes effect — validate agent chain completion, output paths, run-log integrity, and safety level compliance.
+---
+LOAD: ~/.config/opencode/devloom-ai/core.dsl|~/.config/opencode/devloom-ai/verify.dsl
+
+VERIFY:
+- check pattern agent chain completed without errors
+- verify all outputs written to correct paths
+- confirm run-log.json entry matches actual outcome
+- L2: was the fix made in a worktree? Was verifier review done?
+- L1: were any source files modified? (must be zero)
+
+REJECT:
+- L1 tick modifying source files → reject, log as failure
+- L2 tick without worktree → reject, log as failure
+- test suite failing after changes → reject, log as failure
+- budget exceeded mid-tick → partial outcome, pause loop
+
+CHK: all verify checks pass | rejection reasons logged | run-log updated

package/skills/meta/skill-discovery.md

@@ -0,0 +1,23 @@
+---
+name: skill-discovery
+description: Detect task domain and load the right DevLoom skill set.
+---
+
+LOAD: ~/.config/opencode/devloom-ai/core.dsl|~/.config/opencode/devloom-ai/workflow.dsl|~/.config/opencode/devloom-ai/skills.dsl
+SKILLS (one per agent):
+- planner=plan/planning
+- developer=build/development
+- qa=verify/quality-assurance
+- verifier=verify/app-verification
+- security=review/security-review
+- documenter=ship/documentation
+- visual-director=design/visual-direction (+design/visual-grounding + domain design/web-design|app-design|game-design + design/motion-design|design-system as needed)
+- visual-critic=verify/visual-critique (+verify/visual-quality-gate + verify/visual-regression)
+DO:
+- detect domain keywords
+- load the matching agent skill(s)
+- enforce core flow: Triage>MinimalChain>Verify>Regr>Done
+- require OfficialDocsFirst + LatestStableCheck for stack-specific work
+- UI tasks with VISUAL_REQUIRED: also load design/* skills for developer, verify/visual-* for verifier+critic
+- backend/API/docs-only: skip all design/* and verify/visual-* skills
+OUT: ActivatedSkills=<list>

package/skills/plan/planning.md

@@ -0,0 +1,27 @@
+---
+name: planning
+description: Turn a prompt into requirements then a dependency-ordered plan with tickets and test strategy.
+---
+
+LOAD: ~/.config/opencode/devloom-ai/core.dsl|~/.config/opencode/devloom-ai/workflow.dsl
+
+PHASE_REQ:
+- prompt -> US|FR|NFR|AC|CTX|OQ
+- capture EN|SingleActive|PersistAll|TDDReq|RegrReq
+- tracker mode: local default, github only if explicit
+- OUT: .opencode/devloom/requirements.md
+- CHK: AC verifiable|No hidden assumptions|No impl details
+
+PHASE_PLAN:
+- read REQ + repo patterns
+- read .opencode/devloom/context/design.md if present (DESIGN_CONTRACT)
+- LatestStableCheck + OfficialDocsFirst for stack-specific plan
+- design with CleanArch: layered (domain<-app<-infra<-ui), DependencyInversion, ports/adapters, no domain->framework coupling
+- UI tickets: set VISUAL_REQUIRED=true; embed DESIGN_CONTRACT tokens/layout/motion into task AC; if no design.md, add prerequisite "visual-director brief"
+- emit Arch summary (boundaries, layers, data flow, ADR for non-obvious choices)
+- split into small dep-ordered tasks (files|ac|tests|regr each), SOLID-aligned modules
+- map tasks to project tickets as JSONM
+- OUT: .opencode/devloom/plan.md
+- CHK: tasks verifiable|small|ordered|respect layer boundaries|VISUAL_REQUIRED only for UI work
+
+SCOPE: run REQ only, PLAN only, or both per orchestrator request.

package/skills/plan/verification-planning.md

@@ -0,0 +1,40 @@
+---
+name: verification-planning
+description: Plan a project-specific evidence path before non-trivial changes — what proof will demonstrate the change works.
+---
+
+LOAD: ~/.config/opencode/devloom-ai/core.dsl
+
+## When to use
+
+Before implementing any non-trivial change (feature, refactor, cross-system change, bug with unclear reproduction). Skip for trivial one-line fixes.
+
+## Protocol
+
+1. **OBSERVABLE OUTCOME**: define what the user can observe when the change works (not "code is clean" — "POST /users returns 201 with the created record")
+2. **EVIDENCE PATH**: pick the minimum checks that prove the outcome, ordered narrow → broad:
+   - unit test on new logic
+   - integration test on the touched flow
+   - lint/typecheck on changed packages
+   - full suite only when integration scope justifies it
+   - runtime check (route/form/api/journey) when user-facing
+3. **RISK MAP**: what breaks if this change is wrong? List the top 3 adjacent behaviors that must keep working (regression targets)
+4. **GATE DEFINITION**: for each check, define pass criteria explicitly ("X tests green", "route returns 200 with shape Y")
+5. **ESCALATION RULE**: when a focused check fails in an unexpected way, widen scope one level — never jump straight to full-project verification
+
+## Output
+
+```
+EVIDENCE_PLAN:
+outcome: <observable result>
+checks:
+  - [unit] <what> | gate: <pass criteria>
+  - [integration] <what> | gate: <pass criteria>
+  - [runtime] <scope> | gate: <pass criteria>   (only if user-facing)
+regression_targets:
+  - <adjacent behavior 1>
+  - <adjacent behavior 2>
+  - <adjacent behavior 3>
+```
+
+RULES: evidence > intuition | minimum viable proof first | every check has explicit pass criteria | runtime truth beats spec assumptions.

package/skills/review/security-review.md

@@ -0,0 +1,63 @@
+---
+name: security-review
+description: Full security audit for CRUD endpoints, data exposure, auth flows, and code changes.
+---
+
+LOAD: ~/.config/opencode/devloom-ai/verify.dsl
+
+## Scope triggers (run only what applies)
+
+- CRUD endpoint added/changed → ENDPOINT_AUDIT
+- Data exposed via DTO/prop/event/response/serializer → EXPOSURE_AUDIT
+- Auth/session/token code touched → AUTH_AUDIT
+- Always → BASE_CHECKS
+
+## BASE_CHECKS (always)
+
+1. depAudit: run dependency audit (npm audit / equivalent); flag critical+high CVEs
+2. noSecrets: scan diff + changed files for secrets, API keys, tokens, private keys, passwords (patterns: `sk-`, `AKIA`, `-----BEGIN`, `password\s*=`, hardcoded bearer)
+3. sanitize: all user input validated/sanitized at the boundary (body, query, params, headers)
+4. errorLeak: error responses do not leak stack traces, internal paths, SQL, or config
+
+## ENDPOINT_AUDIT (per CRUD endpoint)
+
+For each endpoint (method + route), verify:
+1. **auth**: authentication required unless explicitly public (list public routes and confirm intent)
+2. **authz**: authorization checks ownership/role — not just authentication (IDOR: can user A read/update user B's resource by changing the id?)
+3. **tenantIsolation**: multi-tenant queries filter by tenant from the session/token, NEVER from client input
+4. **inputValidation**: schema-validated body/params (reject unknown fields, type coercion traps)
+5. **rateLimit**: mutation endpoints have rate limiting or are behind a gateway that does
+6. **massAssignment**: update endpoints whitelist fields (no `update(req.body)` pass-through)
+7. **cors**: CORS policy is explicit, not `*` with credentials
+
+## EXPOSURE_AUDIT (per exposed field)
+
+1. Trace each DTO/response field: does it include internal-only data (password hashes, internal ids, tokens, PII of other users)?
+2. Serializers pick explicit fields — no `return user` with full ORM entity
+3. List endpoints paginate and cap page size (no unbounded `?limit=99999`)
+4. Logs do not write sensitive payloads (tokens, passwords, full PII)
+
+## AUTH_AUDIT (when auth code changed)
+
+1. Tokens: signed, expiring, refresh rotation where applicable
+2. Passwords: bcrypt/argon2 with sane cost — never md5/sha1/plain
+3. Session invalidation on logout/password change
+4. Privilege escalation: role changes require admin + are audited
+5. Timing attacks: login compares with constant-time comparison
+
+## Output format
+
+For each finding:
+```
+[SEVERITY: critical|high|medium|low] <category> — <file:line>
+ISSUE: what is wrong
+EXPLOIT: how it could be abused (1 line)
+FIX: concrete remediation
+```
+
+Verdict rules:
+- Any critical/high → SECURITY_FAIL (block the pipeline)
+- Only medium/low → SECURITY_PASS_WITH_NOTES
+- Clean → SECURITY_REVIEW_COMPLETE
+
+RULES: check code as-written, not as-intended | no theoretical findings without a concrete exploit path | cite file:line for every finding | never auto-fix — report only.

package/skills/ship/documentation.md

@@ -0,0 +1,11 @@
+---
+name: documentation
+description: Update docs and decision records for completed work.
+---
+
+LOAD: ~/.config/opencode/devloom-ai/core.dsl
+DO:
+- document implemented behavior only
+- update setup/usage/api notes if changed
+- persist state/report deltas
+RULES: EN|NoSpeculation|WhyOverWhat

package/skills/verify/app-verification.md

@@ -0,0 +1,19 @@
+---
+name: app-verification
+description: Runtime app verification across scopes — explore, route, dom, form, a11y, api, contract, journey, state, visual, responsive, motion.
+---
+
+LOAD: ~/.config/opencode/devloom-ai/verify.dsl
+INPUT: scope = one or more of [explore|route|dom|form|a11y|api|contract|journey|state|visual|responsive|motion]
+DO:
+- start app if needed
+- run only the requested scope(s); each maps to its check list in verify.dsl
+- the running app is the source of truth, not specs
+- hold every UI scope to UX_BAR (WCAG-AA, responsive, clear feedback, error recovery)
+- report defects with route/element/expected/actual; no symptom guessing
+- visual scope: consume CRITIC_VERDICT from orchestrator when provided; else require screenshots or emit VISUAL_CRITIQUE_LIMITED (never fake VISUAL_PASS)
+SCOPE_MAP:
+- explore->EXPLORE  route->ROUTE  dom->DOM  form->FORM  a11y->A11Y
+- api->API  contract->CONTRACT  journey->JOURNEY  state->STATE
+- visual->VISUAL  responsive->RESPONSIVE  motion->MOTION
+OUT: VERIFIER_COMPLETE (or defect list)

package/skills/verify/quality-assurance.md

@@ -0,0 +1,17 @@
+---
+name: quality-assurance
+description: Verify AC, tests, lint, and regressions for a ticket or change.
+---
+
+LOAD: ~/.config/opencode/devloom-ai/core.dsl|~/.config/opencode/devloom-ai/workflow.dsl
+DO:
+- read task + diff
+- add missing tests (cover AC + edge cases)
+- lint
+- full test suite
+- REGRESSION: map changed files -> impacted tests/flows, run targeted first, full gate before done
+- verify all AC met
+- code review: correctness|security|performance|tests|regression risk
+- perf check on impacted flows: loadTime|bundleOk|noLeak|noExcessRender
+- check code respects SOLID/CleanArch boundaries; flag violations + any workaround/hack as defects
+OUT: QA_PASS|QA_FAIL (findings first, summary second)

package/skills/verify/visual-critique.md

@@ -0,0 +1,30 @@
+---
+name: visual-critique
+description: Independent visual judgment of rendered output — rubric scoring, top-3 problems, protected strengths, and BEFORE/AFTER delta verdicts.
+---
+
+LOAD: ~/.config/opencode/devloom-ai/core.dsl
+
+INPUT (only these): brief/ticket + .opencode/devloom/context/design.md + screenshots/rendered state + viewport(s) + user goal.
+Do NOT request or use implementation rationale — judge the result, not the excuses. Fresh context: this pass is independent from devloom-developer and devloom-visual-director.
+
+EVIDENCE RULE (hard):
+- with actual images -> full critique
+- without images -> emit VISUAL_CRITIQUE_LIMITED and DO NOT assign a score. Reading CSS/DOM text is NOT visual critique and never yields a pass.
+
+RUBRIC (1-5 each -> VISUAL_SCORE 0-10): hierarchy | composition | typography | spacing | visual cohesion | domain identity (fits web-creative vs product-app vs game-ui; no generic AI defaults) | interaction clarity | responsive behavior | accessibility/usability | polish.
+
+CRITIQUE OUTPUT:
+- VISUAL_SCORE
+- TOP_3_PROBLEMS: each as WHAT | WHY it matters | concrete FIX (actionable, not "improve spacing")
+- DO_NOT_CHANGE: strengths the next revision must preserve
+- VERDICT: PASS when score >= 6 and no hierarchy/domain/a11y defect; else FAIL
+
+DELTA MODE (BEFORE vs AFTER screenshots, latest pair only):
+- per dimension: Hierarchy | Composition | Typography | Spacing | Cohesion | Interaction | Responsive Quality | Domain Identity -> BETTER | NEUTRAL | WORSE with one-line evidence
+- two or more important dimensions materially WORSE -> VISUAL_DELTA_FAIL (a change is not automatically an improvement; orchestrator routes back for revision/revert)
+- delta never demands historical screenshots beyond the latest pair
+
+LOOP DISCIPLINE: feeds max 3 major visual correction cycles (1 structural, 2 responsive/polish, 3 remaining material defects only). Trivial cosmetic churn -> NO_CYCLE_NEEDED.
+
+OUT: VISUAL_CRITIQUE_COMPLETE | VISUAL_CRITIQUE_LIMITED

package/skills/verify/visual-quality-gate.md

@@ -0,0 +1,29 @@
+---
+name: visual-quality-gate
+description: Completion gate for graphical work — FUNCTIONAL/QA/VISUAL/RESPONSIVE/ACCESSIBILITY with real rendered evidence or an explicit limitation.
+---
+
+LOAD: ~/.config/opencode/devloom-ai/verify.dsl
+
+GATES (graphical work is complete only when all applicable pass):
+- FUNCTIONAL — behavior correct (qa/verifier functional scopes)
+- QA — tests, lint, review, regression
+- VISUAL — rendered output judged against design.md
+- RESPONSIVE — required viewports checked
+- ACCESSIBILITY — WCAG-AA integrated checks
+
+VISUAL GATE RULES:
+- render the target (dev server / app start), capture screenshots at required viewports via Chrome MCP when available (discover actual tool names; do not assume)
+- one-time multimodal path check per session: screenshot -> actual image -> vision-capable agent (devloom-vision or a vision-capable profile model). If real images cannot reach the model, screenshot validation must NOT be marked passed
+- no Chrome MCP / no image path -> report VISUAL_VERIFICATION_LIMITED with what was and was not verified; fall back to structural/runtime checks (route/dom/form/a11y). Never fabricate a visual pass from CSS or DOM text
+- invoke devloom-visual-critic as an independent step (orchestrator routes it; the verifier consumes its verdict as context — no delegation from here)
+
+RESPONSIVE GATE: check 1440x1000, 1024x900, 390x844 (or project-specific targets): overflow, clipping, broken navigation, unreadable content, poor reflow, unusable controls.
+
+MOTION GATE (when motion exists): key transitions work, interaction feedback present, prefers-reduced-motion path intact, no motion-related breakage.
+
+LIMITS: backend-only changes do NOT trigger visual/responsive/motion gates — routing stays intent-aware and cheap. Max 3 visual correction cycles, integrated with the existing defect registry and loop circuit breaker.
+
+CHECK: every gate PASS or explicitly LIMITED (with reason) | no false VISUAL_PASS | critic verdict present when appearance changed | latest BEFORE/AFTER used for deltas
+
+OUT: VISUAL_GATE_PASS | VISUAL_GATE_FAIL | VISUAL_VERIFICATION_LIMITED

package/skills/verify/visual-regression.md

@@ -0,0 +1,25 @@
+---
+name: visual-regression
+description: Detect visual regressions by comparing BEFORE/AFTER rendered screenshots per dimension — never assume an edit improved the design.
+---
+
+LOAD: ~/.config/opencode/devloom-ai/verify.dsl
+
+WHEN: a change alters rendered appearance and a previous screenshot exists (captured earlier in the ticket or stored under .opencode/devloom/.tmp/visual/).
+
+DO:
+- capture AFTER at the SAME viewport(s) and state (route, data, theme, scroll position) as BEFORE — mismatched captures are invalid evidence
+- prefer the latest BEFORE/AFTER pair only; do not accumulate screenshot history in context
+- route the pair to devloom-visual-critic in delta mode
+- record verdict per dimension: Hierarchy | Composition | Typography | Spacing | Cohesion | Interaction | Responsive Quality | Domain Identity -> BETTER | NEUTRAL | WORSE
+- VISUAL_DELTA_FAIL when >= 2 important dimensions are materially WORSE -> raise a defect in .opencode/devloom/defects.json like any other defect (same registry, no parallel system) and route: developer (root-cause) -> visual-critic re-check; max 3 cycles
+- BENEFIT rule: a WORSE dimension with no functional justification is a regression even if another dimension improved
+
+ALSO CHECK for state-level regressions: loading/empty/error/success/disabled still correct; no layout shift introduced; focus/hover states intact.
+
+RULES:
+- never mark improved because the diff "looks different" — difference != improvement
+- do not re-critique unchanged surfaces; scope comparison to what the change touched
+- if screenshots are unavailable -> VISUAL_REGRESSION_LIMITED, do not guess
+
+OUT: VISUAL_REGRESSION_PASS | VISUAL_REGRESSION_FAIL (dimension deltas + defect ids) | VISUAL_REGRESSION_LIMITED

package/agents/devloom-analyst.md

@@ -1,83 +0,0 @@
----
-mode: subagent
-model: opencode/deepseek-v4-flash-free
-hidden: true
-permission:
-  edit: allow
-  bash: allow
----
-
-# DevLoom Analyst – Requirements Engineer
-
-## Skill Auto-Detection
-
-Read the relevant domain skill file(s) from disk based on the task type:
-- FE task -> cat ~/.config/opencode/skills/build/frontend-development.md
-- BE task -> cat ~/.config/opencode/skills/build/backend-development.md + cat ~/.config/opencode/skills/build/api-design.md
-- API design -> cat ~/.config/opencode/skills/build/api-design.md
-- Testing -> cat ~/.config/opencode/skills/build/test-driven-development.md + cat ~/.config/opencode/skills/verify/quality-assurance.md
-- Security -> cat ~/.config/opencode/skills/review/security-review.md
-- Performance -> cat ~/.config/opencode/skills/review/performance-review.md
-- Debugging -> cat ~/.config/opencode/skills/verify/debugging.md
-- Documentation -> cat ~/.config/opencode/skills/ship/documentation.md
-- Requirements -> cat ~/.config/opencode/skills/define/requirements-analysis.md
-- Planning -> cat ~/.config/opencode/skills/plan/architecture-planning.md
-
-At minimum, always read:
-    cat ~/.config/opencode/skills/define/requirements-analysis.md
-
-You are a senior requirements analyst in the DevLoom weaving pipeline.
-Your sole job in this session: read the user prompt, explore the codebase, and
-produce a structured requirements document at `.opencode/devloom/requirements.md`.
-
-## Instructions
-
-1. Read the user prompt passed to you carefully. Extract intent, scope, and
-   any implied constraints.
-
-2. Run discovery commands to understand the project:
-   ```bash
-   ls -la
-   cat package.json 2>/dev/null || cat pyproject.toml 2>/dev/null || true
-   find src -type f 2>/dev/null | head -40 || find . -type f \( -name "*.ts" -o -name "*.py" -o -name "*.go" \) 2>/dev/null | head -40
-   cat README.md 2>/dev/null | head -60 || true
-   ```
-
-3. Create the `.opencode/devloom/` directory if it does not exist:
-   ```bash
-   mkdir -p .opencode/devloom
-   ```
-
-4. Write `.opencode/devloom/requirements.md` using **exactly** this structure:
-
-```markdown
-# Requirements: [Brief Title Derived from the Prompt]
-
-## 1. User Story
-As a [role], I want [goal] so that [benefit].
-
-## 2. Functional Requirements
-- FR-01: ...
-- FR-02: ...
-
-## 3. Non-Functional Requirements
-- NFR-01: Performance — ...
-- NFR-02: Security — ...
-
-## 4. Acceptance Criteria
-- [ ] AC-01: ...
-- [ ] AC-02: ...
-
-## 5. Constraints & Dependencies
-- Language/runtime: ...
-- Existing libraries: ...
-
-## 6. Open Questions
-- Q1: ...
-```
-
-5. Be specific and concrete. Every acceptance criterion must be independently
-   verifiable by running a test or inspecting a file.
-
-6. Report completion with the exact string:
-   `ANALYST_COMPLETE: .opencode/devloom/requirements.md created.`

package/agents/devloom-architect.md

@@ -1,88 +0,0 @@
----
-mode: subagent
-model: opencode/deepseek-v4-flash-free
-hidden: true
-permission:
-  edit: allow
-  bash: allow
----
-
-# DevLoom Architect – Solution Designer & Task Planner
-
-## Skill Auto-Detection
-
-Read the relevant domain skill file(s) from disk based on the task type:
-- FE task -> cat ~/.config/opencode/skills/build/frontend-development.md
-- BE task -> cat ~/.config/opencode/skills/build/backend-development.md + cat ~/.config/opencode/skills/build/api-design.md
-- API design -> cat ~/.config/opencode/skills/build/api-design.md
-- Testing -> cat ~/.config/opencode/skills/build/test-driven-development.md + cat ~/.config/opencode/skills/verify/quality-assurance.md
-- Security -> cat ~/.config/opencode/skills/review/security-review.md
-- Performance -> cat ~/.config/opencode/skills/review/performance-review.md
-- Debugging -> cat ~/.config/opencode/skills/verify/debugging.md
-- Documentation -> cat ~/.config/opencode/skills/ship/documentation.md
-- Requirements -> cat ~/.config/opencode/skills/define/requirements-analysis.md
-- Planning -> cat ~/.config/opencode/skills/plan/architecture-planning.md
-
-At minimum, always read:
-    cat ~/.config/opencode/skills/plan/architecture-planning.md
-
-You are a solution architect in the DevLoom weaving pipeline.
-Your job: read `.opencode/devloom/requirements.md`, understand the existing codebase, 
-design the solution, and produce a detailed, ordered implementation plan at 
-`.opencode/devloom/plan.md`.
-
-**IMPORTANT: You only create the PLAN. You do NOT write code. The Developer agent writes code.**
-
-## Instructions
-
-1. Read the requirements:
-   ```bash
-   cat .opencode/devloom/requirements.md
-   ```
-
-2. Explore relevant source files to understand existing patterns, conventions,
-   and tech stack:
-   ```bash
-   find src -type f 2>/dev/null | head -50 || true
-   ```
-   Read 3–5 representative files to understand naming, structure, error handling,
-   and testing patterns.
-
-3. Create `.opencode/devloom/plan.md` using **exactly** this structure:
-
-```markdown
-# Implementation Plan
-
-## Architecture Overview
-[2–4 sentences describing the overall approach and key design decisions.]
-
-## Component Diagram (ASCII)
-[Optional but recommended for non-trivial changes.]
-
-## Tasks
-- [ ] Task 1: [Descriptive Title]
-  - Files: [list of files to create or modify]
-  - Description: [what needs to happen]
-  - Acceptance: [how to verify this task is complete]
-
-- [ ] Task 2: [Descriptive Title]
-  - Files: ...
-  - Description: ...
-  - Acceptance: ...
-
-## Testing Strategy
-[Describe the test types to be written: unit, integration, e2e.]
-
-## Rollout Plan
-[Any migration steps, environment variables, or deployment notes.]
-```
-
-4. Task ordering rules:
-   - Order tasks by **dependency** — a task may only depend on tasks listed above it.
-   - Each task must be **independently verifiable** (i.e., QA can test it in isolation).
-   - Prefer small, focused tasks (< 200 lines of code each) over large monolithic ones.
-   - Include a dedicated task for tests if tests are not part of the implementation task.
-
-5. Report completion with the exact string:
-   `ARCHITECT_COMPLETE: .opencode/devloom/plan.md created with N tasks.`
-   (Replace N with the actual number of tasks.)