fix(stack): give Vector a readiness-capable config so eager start succeeds

[avallete]

TL;DR

stack start --eager timed out whenever analytics was enabled. The culprit was Vector, not Logflare: Vector ran its bundled demo config, which disables its API, so the health check never answered. The Vector recipe now always loads a stack-owned API config, and stack start failures name the service that failed.

Before

sequenceDiagram
    participant CLI as stack start --eager
    participant Stack as Stack orchestrator
    participant Vector
    CLI->>Stack: start composition
    Stack->>Vector: launch (no --config)
    Note over Vector: bundled demo config<br/>API disabled, fake log lines
    loop readiness, 60s
        Stack->>Vector: GET /health
        Vector--xStack: nothing listening
    end
    Stack-->>CLI: "Composition start had failures"
    Note over CLI: no service named,<br/>looked like an analytics problem

Loading

After

sequenceDiagram
    participant CLI as stack start --eager
    participant Stack as Stack orchestrator
    participant Vector
    CLI->>Stack: start composition
    Note over Stack: prepare writes (atomically)<br/>API config + quiet default pipeline
    Stack->>Vector: launch --config pipeline --config api
    Stack->>Vector: GET /health
    Vector-->>Stack: 200
    Stack-->>CLI: started
    Note over CLI: on any failure:<br/>"vector (id): Service health timed out"

Loading

What changed

• Vector recipe:
  • Always writes a stack-owned API config (api.enabled, address from VECTOR_API_ADDRESS). Vector has no flag or environment variable for this.
  • Loads it as a second --config next to the pipeline config.
  • The pipeline is the caller's configPath when given, otherwise a quiet default that forwards nothing. The demo's fake log lines no longer reach the stack logs.
• Safe file handling: config writes are atomic because background preparation can overlap a start. Destroy removes only the recipe's own files and empty parent directories, so a caller's config stored nearby survives.
• Clearer failures: stack start lists each failed service as service (id): error. Per-service errors are one line that keeps nested causes, instead of a stack trace.

Why only --eager showed it: lazy starts never wake Vector during stack start, so its broken health check stayed hidden.

Out of scope: forwarding service logs into Analytics is still not implemented.

🤖 Generated with Claude Code

[avallete]

/ai-review

[github-actions]

Superseded by a newer AI review

🤖 AI Review

Four reported findings reduce to three distinct issues. Vector can delete a caller-owned pipeline during destroy and can conflict with an existing custom API configuration. The new error formatter can omit deeper causes. All three are confirmed from the checked-out code.

Findings

Severity	Location	Category	Sources	Claim
🟠 MAJOR	packages/stack/src/services/Vector.ts:119	data-loss	codex	Destroying Vector deletes a caller-supplied pipeline if its configPath is inside the generated Vector config directory.
🟠 MAJOR	packages/stack/src/services/Vector.ts:98	compatibility	claude	A caller pipeline with a conflicting API address is now loaded alongside a generated API configuration, without validation or a clear configuration error from prepare.
🟡 MINOR	packages/stack/src/Orchestrator.ts:58	error-handling	claude+codex	Distinct nested errors with the same message cause causeMessage to omit deeper causes.

Stats

Claude findings: 2 · Codex findings: 2 · Confirmed: 3 · Refuted: 0 · Uncertain: 0

---

Models: claude-opus-5-5 + gpt-6-sol · Trigger: manual · Workflow run

This review runs once per PR. A maintainer can request another with a /ai-review comment.

[avallete]

/ai-review

[github-actions]

🤖 AI Review

The Vector readiness change has three minor edge cases: API detection can misclassify caller configs, a crash can leave directories behind after destroy, and a symlink can bypass the owned-path guard. The reported YAML block-scalar rejection does not occur.

Findings

Severity	Location	Category	Sources	Claim
🟡 MINOR	packages/stack/src/services/Vector.ts:73	correctness	claude	The text-based API checks do not reliably identify a top-level api setting. The TOML regex can match api = ... inside a multiline value or nested table, while the YAML regex misses a top-level flow-style mapping.
🟡 MINOR	packages/stack/src/services/Vector.ts:161	resource-cleanup	claude	A process crash during an atomic config write can leave a .vector-write-* directory that prevents Vector service destroy from removing its instance directory.
🟡 MINOR	packages/stack/src/services/Vector.ts:125	path-validation	claude	A symlink to a stack-owned Vector config can bypass the configPath guard. In particular, a symlink to the existing default pipeline is accepted, then becomes dangling when destroy deletes its target.

Refuted findings (kept for transparency, not posted as review comments)

• packages/stack/src/services/Vector.ts:74 (correctness): The YAML API check rejects a valid pipeline because an indented "api": ... line inside a block scalar matches its regex.
  Refuted: Vector.ts:74 uses /^["']?api["']?\s*:/mu, which has no allowance for whitespace before api. An indented line inside a YAML block scalar does not match. This differs from Claude's finding about flow-style YAML being missed.

Stats

Claude findings: 3 · Codex findings: 1 · Confirmed: 3 · Refuted: 1 · Uncertain: 0

---

Models: claude-opus-5-5 + gpt-6-sol · Trigger: manual · Workflow run

This review runs once per PR. A maintainer can request another with a /ai-review comment.