Julian/sar

Files

julian 17c08e6392 chore: initial monorepo scaffold + WDS Phase 1+2 artifacts

- Nx 22.7 monorepo (pnpm 11.1, TypeScript 5.9, Node 24)
- apps/api: NestJS 11 (CJS conforme CODING-RULES.md PGD-DB-004)
- apps/web: React 19 + Vite 8 (ESM)
- libs/shared/api-interface: Zod contract base
- Docker Compose dev: Postgres 18, Valkey 8, MinIO, Mailpit
- WDS artifacts:
  - design-artifacts/A-Product-Brief/ (5 docs canônicos + 16 dialogs)
  - design-artifacts/B-Trigger-Map/ (hub + 4 personas + feature impact)
- Stack canon: STACK.md v2.2 + CODING-RULES.md v2.0 + brand.md
- AGENTS.md + README.md como entrada para devs/agentes

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

2026-05-27 14:34:20 +00:00

2.0 KiB

Raw Permalink Blame History

Execution Patterns (v1.9.0)

Purpose: Critical execution patterns and anti-patterns for the orchestrator.

🚨 FORBIDDEN EXECUTION PATTERNS (NO EXCEPTIONS)

NEVER Chain Multiple Workflow Steps

FORBIDDEN:

# ❌ WRONG - Chaining steps in a loop bypasses per-step error handling
for step in create dev; do
  session=$("$scripts" tmux-wrapper spawn "$step" ...)
  result=$("$scripts" monitor-session "$session" ...)
done

WHY: If the monitoring task crashes mid-loop, ALL subsequent steps are lost. The orchestrator loses visibility even though tmux sessions may have completed successfully.

REQUIRED:

# ✅ CORRECT - Each step is a separate operation with its own error handling
# Step A: Create
session=$("$scripts" tmux-wrapper spawn create ...)
result=$("$scripts" monitor-session "$session" ...)
"$scripts" tmux-wrapper kill "$session"
# VERIFY state before proceeding

# Step B: Dev (only after create verified)
session=$("$scripts" tmux-wrapper spawn dev ...)
result=$("$scripts" monitor-session "$session" ...)
"$scripts" tmux-wrapper kill "$session"
# VERIFY state before proceeding

ALWAYS Verify State After Each Step

After each workflow step completes (create/dev/auto/review), VERIFY state from source of truth before proceeding to the next step:

Story file exists and has expected content (for create-story)
Sprint-status.yaml shows correct status (for dev-story, code-review)
DO NOT rely solely on monitoring output - if monitoring fails, verify directly

IF Monitoring Fails

If story-automator monitor-session or background task monitoring fails:

Check if tmux session still exists: tmux list-sessions | grep {pattern}
Check session status directly: "$scripts" tmux-status-check "$session"
Verify story file / sprint-status regardless of monitoring output
Only escalate after direct verification confirms failure

See also: monitoring-fallback.md for detailed fallback patterns.

2.0 KiB Raw Permalink Blame History