opencastle 0.32.10 → 0.32.12

package/src/dashboard/src/pages/index.astro

@@ -339,6 +339,15 @@ try {
       <div class="chart-card__body" id="panel-chart"></div>
     </section>
 
+    <!-- Recent Sessions (live during active convoy) -->
+    <section class="chart-card" id="detail-sessions-section" data-nav-section>
+      <div class="chart-card__header">
+        <h2 class="chart-card__title">Recent Sessions</h2>
+        <p class="chart-card__desc">Latest agent sessions from observability log</p>
+      </div>
+      <div class="chart-card__body chart-card__body--table" id="detail-sessions-table"></div>
+    </section>
+
     </div><!-- .view-convoy-detail -->
 
 
@@ -693,6 +702,8 @@ try {
     const url = new URL(window.location);
     url.searchParams.delete('convoy');
     history.pushState({}, '', url);
+    const chainNav = document.getElementById('pipeline-chain-nav');
+    if (chainNav) chainNav.remove();
   }
 
   function showConvoyDetailView(convoyId, convoyName) {
@@ -977,7 +988,8 @@ try {
 
   async function renderRecentSessions() {
     var el = document.getElementById('sessions-table');
-    if (!el) return;
+    var detailEl = document.getElementById('detail-sessions-table');
+    if (!el && !detailEl) return;
     try {
       var allEvents = await loadNdjson(base + 'data/events.ndjson');
       var sessions = allEvents.filter(function(e) { return e.type === 'session'; });
@@ -986,7 +998,9 @@ try {
       });
       sessions = sessions.slice(0, 15);
       if (sessions.length === 0) {
-        el.innerHTML = emptyStateHtml('sessions', 'No sessions recorded yet', 'Agent session data will appear here when sessions are logged via opencastle log.');
+        var emptyHtml = emptyStateHtml('sessions', 'No sessions recorded yet', 'Agent session data will appear here when sessions are logged via opencastle log.');
+        if (el) el.innerHTML = emptyHtml;
+        if (detailEl) detailEl.innerHTML = emptyHtml;
         return;
       }
       var thead = '<thead><tr>' +
@@ -1016,9 +1030,13 @@ try {
           '</tr>';
       }
       tbody += '</tbody>';
-      el.innerHTML = '<table class="sessions-table">' + thead + tbody + '</table>';
+      var tableHtml = '<table class="sessions-table">' + thead + tbody + '</table>';
+      if (el) el.innerHTML = tableHtml;
+      if (detailEl) detailEl.innerHTML = tableHtml;
     } catch (e) {
-      el.innerHTML = emptyStateHtml('sessions', 'No sessions recorded yet', 'Agent session data will appear here when sessions are logged.');
+      var errHtml = emptyStateHtml('sessions', 'No sessions recorded yet', 'Agent session data will appear here when sessions are logged.');
+      if (el) el.innerHTML = errHtml;
+      if (detailEl) detailEl.innerHTML = errHtml;
     }
   }
 
@@ -1056,6 +1074,18 @@ try {
       renderEventTimeline(detail);
       renderDetailPanelChart(detail.tasks || []);
       renderDetailReviewsTable(detail.tasks || []);
+      // Show pipeline chain if this convoy is part of a pipeline
+      const convoyListForChain = window.__DASHBOARD_DATA__?.convoyList ?? [];
+      const currentConvoyEntry = convoyListForChain.find(c => c.id === convoyId);
+      if (currentConvoyEntry && currentConvoyEntry.pipeline_id) {
+        const chainConvoys = convoyListForChain
+          .filter(c => c.pipeline_id === currentConvoyEntry.pipeline_id)
+          .sort((a, b) => (a.created_at || '').localeCompare(b.created_at || ''));
+        if (chainConvoys.length > 1) {
+          renderPipelineChain(chainConvoys, convoyId);
+        }
+      }
+      await renderRecentSessions();
     } catch (e) {
       console.error('Failed to load convoy detail:', e);
       renderConvoyDetailHeader(null);
@@ -1165,6 +1195,7 @@ try {
       return;
     }
     const cols = [
+      { key: 'id', label: 'Task ID' },
       { key: 'phase', label: 'Phase' },
       { key: 'agent', label: 'Agent' },
       { key: 'status', label: 'Status' },
@@ -1209,6 +1240,7 @@ try {
         : '<span style="opacity:0.4">\u2014</span>';
       const tokens = t.total_tokens != null ? formatTokens(t.total_tokens) : '\u2014';
       return '<tr>' +
+        '<td class="td-task">' + escapeHtml(t.id || '\u2014') + '</td>' +
         '<td>' + (t.phase != null ? t.phase : '\u2014') + '</td>' +
         '<td class="td-agent">' + escapeHtml(t.agent || '\u2014') + '</td>' +
         '<td>' + statusBadge + '</td>' +

package/src/dashboard/src/styles/dashboard.css

@@ -1961,6 +1961,8 @@ body {
   pointer-events: none;
   box-shadow: 0 4px 12px rgba(0, 0, 0, 0.4);
   text-transform: none;
+  font-family: inherit;
+  font-weight: 400;
 }
 .tooltip-trigger:focus {
   opacity: 1;
@@ -1991,6 +1993,8 @@ body {
   pointer-events: none;
   box-shadow: 0 4px 12px rgba(0, 0, 0, 0.4);
   text-transform: none;
+  font-family: inherit;
+  font-weight: 400;
 }
 
 /* ── Additional Status Badges ── */

package/src/orchestrator/prompts/generate-convoy.prompt.md

@@ -173,25 +173,7 @@ Each task `prompt` must be a **complete, standalone instruction**. Include:
 >
 > **Weak page prompt:** "Build the About page with a bio and skills section." — No foundation references, agent will create its own styles.
 
-### 6. Validate Before Outputting
-
-- [ ] Every task has a unique `id`
-- [ ] Every `depends_on` reference points to a valid `id` defined earlier in the list
-- [ ] No dependency cycles exist
-- [ ] No two parallel tasks share the same `files` entries — group tasks by phase and check each phase for overlaps; resolve with specific file paths or `depends_on` (see Step 2, rule 4)
-- [ ] No `files` entry contains `*`, `?`, or `**` — use plain file paths or directory paths only
-- [ ] Prompts are self-contained — an agent with zero context can execute them
-- [ ] Timeouts are reasonable for the scope of each task
-- [ ] **Dependency completeness**: For every task prompt, scan for imports, references, or usage of files/types/components produced by other tasks. Each such cross-reference MUST have a `depends_on` edge to the producing task.
-- [ ] **Agent domain matching**: Verify each task's `agent` matches the domain — `developer` for code, `testing-expert` for tests, `documentation-writer` for docs, `copywriter` for marketing copy, `ui-ux-expert` for UI components, `database-engineer` for migrations, `security-expert` for auth/security, `data-expert` for ETL/scraping. A `content-engineer` should NOT be assigned to pure TypeScript code tasks.
-- [ ] **File list completeness**: Every file mentioned in a task's prompt that the agent will create or modify MUST appear in that task's `files` list. Don't omit utility files, sub-components, or config files if the prompt instructs the agent to create them.
-- [ ] **Prompt instruction accuracy**: Don't include instructions that contradict the dependency graph. If a task depends on another task (via `depends_on`), the depended task's outputs will exist when this task runs — don't add `@ts-expect-error` comments, stub files, or "if not found" fallbacks for files produced by dependencies.
-- [ ] **Content research rule compliance**: If a prompt concerns real people, places, or organisations, it includes a research instruction telling the agent to search the internet first.
-- [ ] **Foundation phase present**: If the plan involves 2+ pages or UI sections, a `foundation-setup` task exists with no dependencies, and all page tasks depend on it
-- [ ] **Foundation references in page prompts**: Every page-building task prompt includes the 5 mandatory Foundation References (design tokens path, layout path, UI component path, aesthetic direction, content tone)
-- [ ] **No token duplication**: Page task prompts do NOT instruct agents to create new design tokens, layout components, or shared UI primitives — only to import and use existing ones from the foundation
-
-### 7. Output
+### 6. Output
 
 Your response must contain **ONLY** a single ` ```json ` fenced code block — no text before it, no text after it, no explanations, no summaries, no DAG diagrams.
 
@@ -234,6 +216,38 @@ When chain mode is detected:
 }
 ````
 
+## Self-Validation Checklist (MANDATORY)
+
+Before outputting the JSON, verify **every item** below. The downstream validator will reject your plan if any blocking checks fail — fix them now to avoid expensive retry cycles.
+
+### Structural Integrity
+
+- [ ] Every task has a unique `id` (lowercase, kebab-case)
+- [ ] Every `depends_on` reference points to a valid `id` defined in the task list
+- [ ] No dependency cycles exist (DAG is acyclic)
+- [ ] No `files` entry contains `*`, `?`, or `**` — plain paths only
+- [ ] Top-level `name` and `tasks` fields are present; `tasks` is non-empty
+- [ ] Every task has both `id` and `prompt` fields (both non-empty strings)
+
+### Partition & Dependency Coherence
+
+- [ ] No two parallel tasks (same phase / no `depends_on` edge) share any `files` entry — resolve with specific file paths or sequencing
+- [ ] **Dependency completeness**: For every task prompt, scan for imports or references to files/types/components produced by other tasks. Each cross-reference MUST have a `depends_on` edge to the producing task.
+- [ ] **File list completeness**: Every file mentioned in a task's prompt that the agent will create or modify appears in that task's `files` list. Don't omit utility files, sub-components, or config files.
+- [ ] **Prompt-dependency coherence**: Prompts do not include workarounds (stub files, `@ts-expect-error`, conditional imports) for outputs of tasks listed in `depends_on`, since those outputs are guaranteed to exist.
+
+### Prompt Quality
+
+- [ ] **Self-contained**: An agent with zero context can execute the prompt without external clarification.
+- [ ] **File-specific**: Names the exact files to create or modify — no vague references ("the frontend", "the codebase").
+- [ ] **Substantive**: At least 2 meaningful sentences; no stubs (`...`), no placeholders.
+- [ ] **Verifiable**: Contains acceptance criteria or explicit verification steps.
+- [ ] **Agent domain matching**: Each task's `agent` matches the domain — `developer` for code, `testing-expert` for tests, `documentation-writer` for docs, `copywriter` for marketing copy, `ui-ux-expert` for UI, `database-engineer` for migrations, `security-expert` for auth/security, `data-expert` for ETL/scraping.
+- [ ] **Content research compliance**: If a prompt concerns real people, places, or organisations, it includes a research instruction.
+- [ ] **Foundation phase present** (multi-page only): If 2+ pages/UI sections, a `foundation-setup` task exists and all page tasks depend on it with the 5 mandatory Foundation References.
+
+---
+
 ## Historical Performance Context
 
 When historical execution data is available (via `opencastle insights --json`), the Team Lead should include a compact summary in the context. Example:

package/src/orchestrator/prompts/validate-convoy.prompt.md

@@ -8,11 +8,9 @@ output: validation
 
 # Validate Task Plan
 
-> **Note:** Schema validation (field types, YAML syntax, dependency cycles, glob patterns) has already passed. Focus ONLY on the semantic checks below.
+> **Note:** Schema validation (field types, YAML syntax, dependency cycles, glob patterns) has already passed. The generator already enforces prompt quality, agent matching, and file list completeness. Focus ONLY on the structural and logical checks below.
 
-You are a senior technical reviewer. Validate the task plan below for semantic correctness. Be strict — a plan that passes this gate will be executed autonomously by AI agents.
-
-> **⚠ EXHAUSTIVENESS MANDATE**: You MUST report ALL errors in a single pass. Do NOT stop at the first few issues. Systematically evaluate every task against every check below. A second validation pass should find zero new issues — if it would, your first pass was incomplete. Cross-reference every task's prompt against every other task's files list and dependency edges before concluding.
+You are a senior technical reviewer. Validate the task plan below for **structural correctness**. Pass the plan if the structure is sound — do not fail for prompt wording, style, or verbosity.
 
 ## Task Plan to Validate
 
@@ -20,46 +18,31 @@ You are a senior technical reviewer. Validate the task plan below for semantic c
 
 ---
 
-## Semantic Checks
+## Validation Checks
 
-> If the spec below contains the marker `<!-- validation-pass: N -->`, this is validation pass N. On pass 1, be maximally thorough — report every issue you can find. On pass 2+, verify that previous fixes were applied correctly and check for regressions, but do NOT invent new categories of issues not covered by the checks below.
+> If the spec contains `<!-- validation-pass: N -->`, this is pass N. On pass 2+, verify previous fixes were applied — do NOT invent new issues.
 
-Evaluate **every check** below. If ALL pass, respond `VALID`. If ANY fail, respond `INVALID` with specific, actionable errors.
+Evaluate the checks below. If ALL pass, respond `VALID`. Only fail for checks marked BLOCKING.
 
-### 1. Partition Conflicts
+### Partition Conflicts (BLOCKING)
 
 Two tasks that can run in parallel (no direct or transitive `depends_on` edge between them) must not share any `files` entry.
 
 - [ ] For every pair of potentially-parallel tasks, confirm they share no file or directory path in their `files` lists
 - [ ] Transitive dependencies count: if A → B → C, then A and C are NOT parallel
 
-### 2. Prompt Quality
-
-Each task `prompt` must be:
-
-- [ ] **Self-contained** — an agent with zero context can execute it without external clarification
-- [ ] **File-specific** — names the exact files to create or modify (not vague references like "the frontend" or "the codebase")
-- [ ] **Substantive** — at least 2 meaningful sentences; no stubs (`...`), no placeholders
-- [ ] **Verifiable** — contains acceptance criteria or explicit verification steps
-- [ ] **Research-instructed** — if the prompt concerns real people, places, or organisations, it includes a research instruction
-
-### 3. Dependency Completeness
-
-If a task's prompt imports, references, or builds on files, types, components, or packages produced by another task, a `depends_on` edge to that producing task must exist.
+### Dependency Completeness (BLOCKING)
 
-- [ ] Scan every prompt for cross-task file imports, type usage, or component references
-- [ ] Each such reference must be covered by a `depends_on` edge to the task that creates it
+If a task's prompt imports, references, or builds on files produced by another task, a `depends_on` edge to that producing task must exist.
 
-### 4. Logical Soundness
+- [ ] Scan every prompt for cross-task file references
+- [ ] Each such reference must be covered by a `depends_on` edge
 
-The overall plan must make engineering sense.
+### Logical Soundness (BLOCKING)
 
 - [ ] No redundant tasks doing the same work
-- [ ] No obvious missing tasks (gaps that would leave the goal unachievable)
-- [ ] File ownership matches task descriptions (a task that owns a file should actually modify it)
-- [ ] Agent assignment matches domain — `developer` for code, `documentation-writer` for docs, `copywriter` for marketing copy, etc.
-- [ ] File list completeness — every file the prompt instructs the agent to create/modify appears in the task's `files` list
-- [ ] Prompt-dependency coherence — prompts do not include workarounds (stub files, `@ts-expect-error`, conditional imports) for outputs of tasks listed in `depends_on`, since those outputs are guaranteed to exist
+- [ ] No obvious missing tasks that would leave the goal unachievable
+- [ ] No tasks with empty or stub prompts (`...`, placeholder text)
 
 ---