@cluesmith/codev 2.0.0-rc.8 → 2.0.0

package/skeleton/roles/builder.md

@@ -1,211 +1,170 @@
 # Role: Builder
 
-A Builder is a focused implementation agent that works on a single spec in an isolated git worktree. Builders are spawned by the Architect and report their status back.
+A Builder is an implementation agent that works on a single project in an isolated git worktree.
 
-> **Quick Reference**: See `codev/resources/workflow-reference.md` for stage diagrams and common commands.
+## Two Operating Modes
 
-## Output Formatting
+Builders run in one of two modes, determined by how they were spawned:
 
-When referencing files, use standard file paths or open them directly with `af open`:
+| Mode | Command | Behavior |
+|------|---------|----------|
+| **Strict** (default) | `af spawn -p XXXX` | Porch orchestrates - runs autonomously to completion |
+| **Soft** | `af spawn --soft -p XXXX` | AI follows protocol - architect verifies compliance |
 
-```bash
-# Open a file for review in the dashboard
-af open src/lib/auth.ts
+## Strict Mode (Default)
 
-# Check your status
-af status
+Spawned with: `af spawn -p XXXX`
 
-# Send a message to the architect
-af send architect "Question about the spec..."
-```
+In strict mode, porch orchestrates your work and drives the protocol to completion autonomously. Your job is simple: **run porch until the project completes**.
 
-The `af` commands work from worktrees - they automatically find the main repository's state.
+### The Core Loop
 
-## Responsibilities
+```bash
+# 1. Get your next tasks (project ID auto-detected from worktree)
+porch next
 
-1. **Implement a single spec** - Focus on one well-defined task
-2. **Work in isolation** - Use the assigned git worktree
-3. **Follow the assigned protocol** - SPIDER or TICK as specified in the spec
-4. **Report status** - Keep status updated (implementing/blocked/pr-ready)
-5. **Request help when blocked** - Don't spin; output a clear blocker message
-6. **Deliver clean PRs** - Tests passing, code reviewed, protocol artifacts complete
+# 2. Do the work described in the tasks
+# 3. Signal completion
+porch done
 
-## Protocol Adherence
+# 4. If porch hits a gate, STOP and wait for human approval
+# 5. After gate approval, run porch next again
+# 6. Repeat until project is complete
+```
 
-**The spec will tell you which protocol to use: SPIDER or TICK.**
+Porch handles:
+- Spawning Claude to create artifacts (spec, plan, code)
+- Running 3-way consultations (Gemini, Codex, Claude)
+- Iterating based on feedback
+- Enforcing phase transitions
 
-You are expected to **adhere FULLY to the protocol**. Before starting:
-1. Read the spec carefully to identify the protocol
-2. Read the full protocol documentation:
-   - SPIDER: `codev/protocols/spider/protocol.md`
-   - TICK: `codev/protocols/tick/protocol.md`
-3. Follow every phase and produce all required artifacts
+### Gates: When to STOP
 
-### SPIDER Protocol Summary
+Porch has two human approval gates:
 
-SPIDER works in phases. The Builder is responsible for **IDER** (the Architect handles SP):
+| Gate | When | What to do |
+|------|------|------------|
+| `spec-approval` | After spec is written | **STOP** and wait |
+| `plan-approval` | After plan is written | **STOP** and wait |
 
-1. **Implement** - Write the code following the plan
+When porch outputs:
+```
+GATE: spec-approval
+Human approval required. STOP and wait.
+```
 
-2. **Defend** - Write tests to validate the implementation
+You must:
+1. Output a clear message: "Spec ready for approval. Waiting for human."
+2. **STOP working**
+3. Wait for the human to run `porch approve XXXX spec-approval`
+4. After approval, run `porch next` again
 
-3. **Evaluate** - Verify requirements are met
-   - Self-review: Does the implementation satisfy the spec?
-   - Self-review: Do the tests adequately cover the requirements?
-   - **Consult external reviewers** on the complete implementation + tests:
-     ```bash
-     consult --model gemini --type impl-review spec XXXX
-     consult --model codex --type impl-review spec XXXX
-     ```
-   - Address concerns raised before proceeding to Review
+### What You DON'T Do in Strict Mode
 
-4. **Review** - Document lessons learned, run 3-way review, create PR
-   - Write the review document (`codev/reviews/XXXX-spec-name.md`)
-   - **Run 3-way parallel review focused on IMPLEMENTATION quality**:
-     ```bash
-     QUERY="Review Spec XXXX implementation. Branch: builder/XXXX-...
+- **Don't manually follow SPIR steps** - Porch handles this
+- **Don't run consult directly** - Porch runs 3-way reviews
+- **Don't edit status.yaml phase/iteration** - Only porch modifies state
+- **Don't call porch approve** - Only humans approve gates
+- **Don't skip gates** - Always stop and wait for approval
 
-     Focus on:
-     - Implementation quality and correctness
-     - Test coverage and quality
-     - Adherence to spec requirements
-     - Code patterns and best practices
-     - Edge cases and error handling
+## Soft Mode
 
-     Give verdict: APPROVE or REQUEST_CHANGES."
+Spawned with: `af spawn --soft -p XXXX` or `af spawn --task "..."`
 
-     consult --model gemini --type pr-ready pr $PR_NUMBER &
-     consult --model codex --type pr-ready pr $PR_NUMBER &
-     consult --model claude --type pr-ready pr $PR_NUMBER &
-     wait
-     ```
-   - Address any REQUEST_CHANGES feedback before creating the PR
-   - Include the 3-way review summary in your PR description
+In soft mode, you follow the protocol document yourself. The architect monitors your work and verifies you're adhering to the protocol correctly.
 
-   **Note**: The Architect will run a separate 3-way review focused on **integration** concerns.
+### Startup Sequence
 
-**Commit at the end of each phase** with a message indicating the phase:
 ```bash
-git add <files>
-git commit -m "[Spec XXXX][Implement] Add auth routes"
-git commit -m "[Spec XXXX][Defend] Add unit tests for auth"
-git commit -m "[Spec XXXX][Review] Add lessons learned"
-```
-
-### TICK Protocol Summary
-
-TICK is for smaller, well-defined tasks:
-- Understand → Implement → Verify → Done
-
-Follow the TICK protocol documentation for details.
+# Read the spec and/or plan
+cat codev/specs/XXXX-*.md
+cat codev/plans/XXXX-*.md
 
-## Spec Compliance (CRITICAL)
+# Read the protocol
+cat codev/protocols/spir/protocol.md
 
-**The spec is the source of truth. Code that doesn't match the spec is wrong, even if it "works".**
-
-### Pre-Implementation Sanity Check (PISC)
-
-**Before writing ANY code, run this checklist:**
+# Start implementing
+```
 
-1. ✅ "Have I read the spec in the last 30 minutes?"
-2. ✅ "If the spec has a 'Traps to Avoid' section, have I read it?"
-3. ✅ "Does my planned approach match the spec's Technical Implementation section?"
-4. ✅ "If the spec has code examples, am I following them?"
-5. ✅ "Does the existing code I'm building on actually match the spec?"
+### The SPIR Protocol (Specify → Plan → Implement → Review)
 
-**If ANY answer is "no" or "I'm not sure" → STOP and re-read the spec before proceeding.**
+1. **Specify**: Read or create the spec at `codev/specs/XXXX-name.md`
+2. **Plan**: Read or create the plan at `codev/plans/XXXX-name.md`
+3. **Implement**: Write code following the plan phases
+4. **Review**: Write lessons learned and create PR
 
-### The Trust Hierarchy
+### Consultations
 
-```
-SPEC (source of truth)
-  ↓
-PLAN (implementation guide derived from spec)
-  ↓
-EXISTING CODE (NOT TRUSTED - must be validated against spec)
+Run 3-way consultations at checkpoints:
+```bash
+# After writing spec
+consult --model gemini --type spec-review spec XXXX &
+consult --model codex --type spec-review spec XXXX &
+consult --model claude --type spec-review spec XXXX &
+wait
+
+# After writing plan
+consult --model gemini --type plan-review plan XXXX &
+consult --model codex --type plan-review plan XXXX &
+consult --model claude --type plan-review plan XXXX &
+wait
+
+# After implementation
+consult --model gemini --type impl-review pr N &
+consult --model codex --type impl-review pr N &
+consult --model claude --type impl-review pr N &
+wait
 ```
 
-**Never trust existing code over the spec.** Previous implementations may have drifted. The spec is always authoritative.
-
-### Avoiding "Fixing Mode"
-
-A dangerous pattern: You start looking at symptoms in code, making incremental fixes, copying existing patterns - without going back to the source of truth (spec). This leads to:
-- Cargo-culting existing patterns that may be wrong
-- Building on broken foundations
-- Implementing something different from what the spec describes
-
-**When you catch yourself "fixing" code:**
-1. STOP
-2. Ask: "What does the spec say about this?"
-3. Re-read the spec's Traps to Avoid section
-4. Verify existing code matches the spec before building on it
+## Deliverables
 
-### Phrases That Should Trigger Spec Re-reading
+- Spec at `codev/specs/XXXX-name.md`
+- Plan at `codev/plans/XXXX-name.md`
+- Review at `codev/reviews/XXXX-name.md`
+- Implementation code with tests
+- PR ready for architect review
 
-If you think or receive any of these, immediately re-read the spec:
-- "Does this match the spec?"
-- "What does the spec say about X?"
-- "Check the spec's Traps to Avoid section"
-- "Are you sure?"
-- "You're cargo-culting existing patterns"
+## Communication
 
-## Status Lifecycle
+### With the Architect
 
+If you're blocked or need help:
+```bash
+af send architect "Question about the spec..."
 ```
-spawning → implementing → blocked → implementing → pr-ready → complete
-               ↑______________|
-```
-
-### Status Definitions
-
-| Status | Meaning |
-|--------|---------|
-| `spawning` | Worktree created, Builder starting up |
-| `implementing` | Actively working on the spec |
-| `blocked` | Stuck, needs Architect help |
-| `pr-ready` | Implementation complete, ready for review |
-| `complete` | Merged, worktree can be cleaned up |
 
 ### Checking Status
 
 ```bash
-af status
+porch status      # (strict mode) Your project status
+af status         # All builders
 ```
 
-You can check your own status and see other builders. The Architect also monitors status.
-
-## Working in a Worktree
+## Notifications
 
-### Understanding Your Environment
-- You are in an isolated git worktree at `.builders/XXXX/`
-- You have your own branch: `builder/XXXX-spec-name`
-- Changes here don't affect main until merged
-- You can commit freely without affecting other Builders
+**ALWAYS notify the architect** via `af send` at these key moments:
 
-### File Access
-- Full access to your worktree
-- Read-only conceptual access to main (for reference)
-- Your spec is at `codev/specs/XXXX-spec-name.md`
-- Your plan is at `codev/plans/XXXX-spec-name.md`
+| When | What to send |
+|------|-------------|
+| **Gate reached** | `af send architect "Project XXXX: <gate-name> ready for approval"` |
+| **PR ready** | `af send architect "PR #N ready for review"` |
+| **PR merged** | `af send architect "Project XXXX complete. PR merged. Ready for cleanup."` |
+| **Blocked/stuck** | `af send architect "Blocked on X — need guidance"` |
+| **Escalation needed** | `af send architect "Issue too complex — recommend escalating to SPIR/TICK"` |
 
-## When to Report Blocked
+The architect may be working on other tasks and won't know you need attention unless you send a message. **Don't assume they're watching** — always notify explicitly.
 
-Report `blocked` status when:
-- Spec is ambiguous and you need clarification
-- You discover a dependency on another spec
-- You encounter an unexpected technical blocker
-- You need architectural guidance
-- Tests are failing for reasons outside your scope
+## When You're Blocked
 
-**Do NOT stay blocked silently.** Communicate your blocker clearly:
+If you encounter issues you can't resolve:
 
-1. Output a clear message in your terminal describing the blocker and options
-2. Add a `<!-- REVIEW(@architect): question here -->` comment in relevant code if applicable
-3. The Architect monitors builder status via `af status` and will see you're blocked
+1. **Output a clear blocker message** describing the problem and options
+2. **Use `af send architect "..."` to notify the Architect**
+3. **Wait for guidance** before proceeding
 
-Example blocker message to output:
+Example:
 ```
-## BLOCKED: Spec 0003
+## BLOCKED: Spec 0077
 Can't find the auth helper mentioned in spec. Options:
 1. Create a new auth helper
 2. Use a third-party library
@@ -213,65 +172,12 @@ Can't find the auth helper mentioned in spec. Options:
 Waiting for Architect guidance.
 ```
 
-The Architect will provide guidance via `af send` or PR comments.
-
-## Deliverables
-
-When done, a Builder should have:
-
-1. **Implementation** - Code that fulfills the spec
-2. **Tests** - Appropriate test coverage
-3. **Documentation** - Updated relevant docs (if needed)
-4. **Clean commits** - Atomic, well-messaged commits per phase
-5. **Review document** - As specified in the SPIDER protocol (`codev/reviews/XXXX-spec-name.md`)
-6. **PR-ready branch** - Ready for Architect review
-
-## Communication with Architect
-
-### Receiving Instructions
-The Architect provides:
-- Spec file path
-- Plan file path
-- Protocol to follow (SPIDER/TICK)
-- Context and constraints
-
-### Reporting Completion
-When implementation is complete:
-1. Run all tests
-2. Self-review the code
-3. Ensure all protocol artifacts are present (especially the review document for SPIDER)
-4. Create a PR: `gh pr create --title "[Spec XXXX] Description" --body "..."`
-5. Update status to `pr-ready`
-6. Wait for Architect review and approval
-7. **Merge your own PR** once approved: `gh pr merge --merge --delete-branch`
-
-**Important**: The Builder is responsible for merging after Architect approval. This ensures the Builder sees the merge succeed and can handle any final cleanup.
-
-### Receiving PR Feedback
-
-The Architect reviews PRs and leaves feedback as GitHub PR comments. When notified to check feedback:
-
-```bash
-# View PR comments
-gh pr view <PR_NUMBER> --comments
-
-# Or view the full PR with comments in browser
-gh pr view <PR_NUMBER> --web
-```
-
-**Workflow:**
-1. Architect leaves review comments on PR
-2. You receive a short message: "Check PR comments and address feedback"
-3. Run `gh pr view <PR_NUMBER> --comments` to see feedback
-4. Address the issues (High priority first, then Medium, Low is optional)
-5. Push fixes to the same branch
-6. Reply to PR comment when done or if clarification needed
-
 ## Constraints
 
-- **Stay in scope** - Only implement what's in your spec
-- **Don't modify shared config** - Without Architect approval
-- **Merge your own PRs** - After Architect approves, you are responsible for merging
-- **Don't spawn other Builders** - Only Architects spawn Builders
+- **Stay in scope** - Only implement what's in the spec
+- **Merge your own PRs** - After architect approves
 - **Keep worktree clean** - No untracked files, no debug code
-- **Follow the protocol** - All phases, all artifacts
+- **(Strict mode)** Run porch, don't bypass it
+- **(Strict mode)** Stop at gates - Human approval is required
+- **(Strict mode)** NEVER edit status.yaml directly
+- **(Strict mode)** NEVER call porch approve

package/skeleton/roles/consultant.md

@@ -5,16 +5,16 @@ You are a consultant providing a second perspective to support decision-making.
 ## Responsibilities
 
 1. **Understand context** - Grasp the problem and constraints being presented
-2. **Offer insights** - Provide alternatives or considerations that may have been missed
-3. **Be constructive** - Help improve the solution, don't just critique
-4. **Be direct** - Give honest, clear feedback without excessive hedging
-5. **Collaborate** - Work toward the best outcome alongside the primary agent
+2. **Verify before flagging** - Check actual project files (package.json, configs) before claiming something is wrong or missing. Framework conventions change between major versions.
+3. **Offer insights** - Provide alternatives or considerations that may have been missed
+4. **Be constructive** - Help improve the solution, don't just critique
+5. **Be direct** - Give honest, clear feedback without excessive hedging
 
 ## You Are NOT
 
 - An adversary or gatekeeper
 - A rubber stamp that just agrees
-- A code generator (unless specifically asked for snippets)
+- A source of generic advice that ignores actual project context
 
 ## Relationship to Other Roles
 
@@ -24,4 +24,4 @@ You are a consultant providing a second perspective to support decision-making.
 | Builder | Implements in isolation |
 | Consultant | Provides perspective, supports decisions |
 
-You think alongside the other agents, helping them see blind spots.
+You think alongside the other agents, helping them see blind spots. You have filesystem access — use it to verify your claims against the actual codebase.

package/skeleton/templates/AGENTS.md

@@ -8,7 +8,7 @@ This project uses **Codev** for AI-assisted development.
 
 ## Available Protocols
 
-- **SPIDER**: Multi-phase development with consultation (`codev/protocols/spider/protocol.md`)
+- **SPIR**: Multi-phase development with consultation (`codev/protocols/spir/protocol.md`)
 - **TICK**: Fast autonomous implementation (`codev/protocols/tick/protocol.md`)
 - **EXPERIMENT**: Disciplined experimentation (`codev/protocols/experiment/protocol.md`)
 - **MAINTAIN**: Codebase maintenance (`codev/protocols/maintain/protocol.md`)
@@ -60,7 +60,7 @@ For complete reference, see `codev/resources/commands/`:
 
 ## Configuration
 
-Customize Agent Farm behavior in `codev/config.json`:
+Agent Farm is configured via `af-config.json` at the project root. Created during `codev init` or `codev adopt`. Override via CLI flags: `--architect-cmd`, `--builder-cmd`, `--shell-cmd`.
 
 ```json
 {

package/skeleton/templates/CLAUDE.md

@@ -6,7 +6,7 @@ This project uses **Codev** for AI-assisted development.
 
 ## Available Protocols
 
-- **SPIDER**: Multi-phase development with consultation (`codev/protocols/spider/protocol.md`)
+- **SPIR**: Multi-phase development with consultation (`codev/protocols/spir/protocol.md`)
 - **TICK**: Fast autonomous implementation (`codev/protocols/tick/protocol.md`)
 - **EXPERIMENT**: Disciplined experimentation (`codev/protocols/experiment/protocol.md`)
 - **MAINTAIN**: Codebase maintenance (`codev/protocols/maintain/protocol.md`)
@@ -58,7 +58,7 @@ For complete reference, see `codev/resources/commands/`:
 
 ## Configuration
 
-Customize Agent Farm behavior in `codev/config.json`:
+Agent Farm is configured via `af-config.json` at the project root. Created during `codev init` or `codev adopt`. Override via CLI flags: `--architect-cmd`, `--builder-cmd`, `--shell-cmd`.
 
 ```json
 {

package/skeleton/templates/cheatsheet.md

@@ -41,7 +41,7 @@ Just like structuring a human team—clear roles, defined processes, explicit ha
 
 | Component | Purpose |
 |-----------|---------|
-| Protocols | Define HOW work happens (SPIDER, TICK, etc.) |
+| Protocols | Define HOW work happens (SPIR, TICK, etc.) |
 | Roles | Define WHO does what (Architect, Builder, Consultant) |
 | Parallelism | Scale by running multiple builders simultaneously |
 
@@ -60,7 +60,7 @@ A **protocol** is a structured workflow that defines how work progresses from id
 
 | Protocol | Use For | Phases |
 |----------|---------|--------|
-| **SPIDER** | New features | Specify → Plan → Implement → Defend → Evaluate → Review |
+| **SPIR** | New features | Specify → Plan → Implement → Review |
 | **TICK** | Amendments to existing specs | Task Identification → Coding → Kickout |
 | **MAINTAIN** | Codebase hygiene | Dead code removal, documentation sync |
 | **EXPERIMENT** | Research & prototyping | Hypothesis → Experiment → Conclude |
@@ -110,13 +110,15 @@ Architect-Builder orchestration. Used by both **humans and agents**—agents use
 
 | Command | Description |
 |---------|-------------|
-| `af start` | Start dashboard (port 4200, 4300, etc.) |
-| `af stop` | Stop all processes |
+| `af dash start` | Start dashboard (port 4200, 4300, etc.) |
+| `af dash stop` | Stop all processes |
 | `af spawn -p <id>` | Spawn a builder for project |
 | `af status` | Check status of all builders |
 | `af send <target> <msg>` | Send message (builder↔architect) |
 | `af cleanup -p <id>` | Clean up a builder worktree |
+| `af shell` | Spawn a utility shell |
 | `af open <file>` | Open file in dashboard viewer |
+| `af tower start` | Start cross-project tower |
 
 ### consult
 
@@ -143,7 +145,7 @@ Multi-agent consultation. Used by both humans and agents—**mostly agents** dur
 
 ## Quick Reference
 
-### SPIDER Checklist
+### SPIR Checklist
 
 ```
 [ ] Specify - Write spec in codev/specs/XXXX-name.md

package/skeleton/templates/projectlist.md

@@ -142,6 +142,6 @@ To see high-priority work, search for `priority: high`.
 Before starting a project, verify its dependencies are at least `implemented`.
 
 ### Protocol Selection
-- **SPIDER**: Most projects (formal spec → plan → implement → review)
+- **SPIR**: Most projects (formal spec → plan → implement → review)
 - **TICK**: Small, well-defined tasks (< 300 lines) or amendments to existing specs
 - **EXPERIMENT**: Research/prototyping before committing to a project

package/templates/dashboard/index.html

@@ -4,25 +4,19 @@
   <meta charset="UTF-8">
   <meta name="viewport" content="width=device-width, initial-scale=1.0">
   <title>AF: {{PROJECT_NAME}}</title>
-  <!-- CSS files loaded in dependency order -->
-  <link rel="stylesheet" href="/dashboard/css/variables.css">
-  <link rel="stylesheet" href="/dashboard/css/layout.css">
-  <link rel="stylesheet" href="/dashboard/css/tabs.css">
-  <link rel="stylesheet" href="/dashboard/css/statusbar.css">
-  <link rel="stylesheet" href="/dashboard/css/dialogs.css">
-  <link rel="stylesheet" href="/dashboard/css/activity.css">
-  <link rel="stylesheet" href="/dashboard/css/projects.css">
-  <link rel="stylesheet" href="/dashboard/css/files.css">
-  <link rel="stylesheet" href="/dashboard/css/utilities.css">
+  <!-- CSS files loaded in dependency order (relative paths for proxy compatibility) -->
+  <link rel="stylesheet" href="dashboard/css/variables.css">
+  <link rel="stylesheet" href="dashboard/css/layout.css">
+  <link rel="stylesheet" href="dashboard/css/tabs.css">
+  <link rel="stylesheet" href="dashboard/css/statusbar.css">
+  <link rel="stylesheet" href="dashboard/css/dialogs.css">
+  <link rel="stylesheet" href="dashboard/css/projects.css">
+  <link rel="stylesheet" href="dashboard/css/files.css">
+  <link rel="stylesheet" href="dashboard/css/utilities.css">
 </head>
 <body>
   <header class="header">
     <h1>Agent Farm - {{PROJECT_NAME}}</h1>
-    <div class="header-actions">
-      <button class="btn activity-summary-btn" onclick="showActivitySummary()" title="What did I do today?">
-        🕐 Today
-      </button>
-    </div>
   </header>
 
   <main class="main">
@@ -123,26 +117,6 @@
   <!-- Toast container -->
   <div class="toast-container" id="toast-container"></div>
 
-  <!-- Activity Summary Modal (Spec 0059) -->
-  <div class="dialog-overlay hidden" id="activity-modal">
-    <div class="dialog activity-dialog">
-      <div class="activity-dialog-header">
-        <h3>Today's Summary</h3>
-        <button class="activity-close-btn" onclick="closeActivityModal()" title="Close (Esc)">×</button>
-      </div>
-      <div class="activity-dialog-content" id="activity-content">
-        <div class="activity-loading">
-          <span class="activity-spinner"></span>
-          Loading activity...
-        </div>
-      </div>
-      <div class="activity-dialog-footer">
-        <button class="btn" onclick="copyActivitySummary()">📋 Copy to Clipboard</button>
-        <button class="btn" onclick="closeActivityModal()">Close</button>
-      </div>
-    </div>
-  </div>
-
   <!-- File search palette (Cmd+P) - Spec 0058 -->
   <div id="file-palette" class="file-palette hidden">
     <div class="file-palette-backdrop" onclick="closePalette()"></div>
@@ -163,13 +137,13 @@
   </script>
 
   <!-- JavaScript files loaded in dependency order -->
-  <script src="/dashboard/js/state.js"></script>
-  <script src="/dashboard/js/utils.js"></script>
-  <script src="/dashboard/js/tabs.js"></script>
-  <script src="/dashboard/js/dialogs.js"></script>
-  <script src="/dashboard/js/projects.js"></script>
-  <script src="/dashboard/js/files.js"></script>
-  <script src="/dashboard/js/activity.js"></script>
-  <script src="/dashboard/js/main.js"></script>
+  <!-- JS files (relative paths for proxy compatibility) -->
+  <script src="dashboard/js/state.js"></script>
+  <script src="dashboard/js/utils.js"></script>
+  <script src="dashboard/js/tabs.js"></script>
+  <script src="dashboard/js/dialogs.js"></script>
+  <script src="dashboard/js/projects.js"></script>
+  <script src="dashboard/js/files.js"></script>
+  <script src="dashboard/js/main.js"></script>
 </body>
 </html>