@exellix/ai-tasks 9.1.0 → 10.0.0

package/documenations/run-task-single-run-checklist.md

@@ -1,109 +0,0 @@
-# Checklist: `@exellix/ai-tasks` — single `runTask` validation
-
-**Scope:** One task node, end-to-end: validate a single `runTask` execution with structured synthesis and MAIN consumption.
-
-**Package context:** PRE steps can include `synthesized-context`; MAIN runs after PRE. Observability is attached on the response as `metadata` (and `meta` alias), including flags such as `synthesizedContextPresent`, `mainContextSource`, and `detectedTemplateCores`.
-
-## Design stance: no backward compatibility
-
-**Backward compatibility with legacy context assembly is not a goal for this stack.** The checklist assumes structured synthesis and MAIN consumption of `executionMemory.synthesizedContext` as the normal, required path.
-
-Today **only one package upstream** still relies on legacy behavior; that integration is expected to be corrected there using this document as the contract for what “good” looks like. Do not preserve or design around legacy paths for other callers—there are none.
-
-Legacy signals in code or metadata (for example `mainContextSource === "legacy"`, primary `webContextMarkdown`, raw Narrix-as-context) are **diagnostics only** (misconfiguration or upstream not yet aligned with this checklist). They are **not** pass criteria and **not** a surface we commit to keeping stable.
-
----
-
-## 1. Template core detection
-
-| # | Check | How to validate | Pass |
-|---|--------|-----------------|------|
-| 1.1 | Resolved template is the real source of task semantics | Trace which template/skill resolved for the run; confirm it matches the intended task definition (not a stale or default template). | |
-| 1.2 | Core tokens come from the **template**, not from free-form request input | Inspect core discovery path: cores should be derived from rendered template content (e.g. `discoverTemplateCores`), not from arbitrary client fields unless explicitly documented. | |
-| 1.3 | Detected core set is visible in logs, traces, or debug output | Confirm `detectedTemplateCores` (or equivalent) appears in tracing/phase metadata or debug logs for the PRE step. | |
-| 1.4 | Behavior when **no** core tokens are found | Run a template with no detectable cores; document expected behavior (empty `templateCores`, synthesis contract, warnings). No silent mis-assumption that cores exist. | |
-| 1.5 | **Multiple** cores preserved | Template with several cores → artifact / observability lists all distinct cores, order stable or documented. | |
-
----
-
-## 2. Structured synthesis execution
-
-| # | Check | How to validate | Pass |
-|---|--------|-----------------|------|
-| 2.1 | PRE synthesized-context **actually runs** | Trace `phase: pipeline_pre`, `preStepType: synthesized-context` (or equivalent) completes without skip. | |
-| 2.2 | Synthesis runs **before** MAIN | Ordering: PRE steps complete, `executionMemory` updated, then MAIN step executes. | |
-| 2.3 | Synthesis input includes | Verify synthesizer payload / source material includes: **resolved question**; **detected template core set**; **raw/enriched local context**; **raw/enriched supporting context** (per `contextSourcePolicy` / `synthesisInputStrategy`). | |
-| 2.4 | Synthesis goes through **ai-gateway** | Network/trace shows gateway route for the synthesis model call, not a bypass. | |
-| 2.5 | Effective mode is **structured**, not fallback markdown assembly | `synthesisMode` / `synthesisOutputFormat` resolves to structured path; response parses as structured payload (e.g. validated JSON contract), not only legacy section markdown. | |
-
----
-
-## 3. Synthesized artifact creation
-
-| # | Check | How to validate | Pass |
-|---|--------|-----------------|------|
-| 3.1 | `executionMemory.synthesizedContext` is produced | Inspect `request`/`result` execution memory after PRE. | |
-| 3.2 | Exists **after PRE** and **before MAIN** | Breakpoint or ordered logs: artifact present when MAIN starts. | |
-| 3.3 | Shape is **structured** (not “only markdown”) | Artifact has structured fields (e.g. validated `payload`, `templateCores`), not solely a prose blob. | |
-| 3.4 | Meaningful **synthesized** local/supporting outputs | Content is distilled/structured per contract, not a verbatim dump of raw Narrix/web/memory. | |
-| 3.5 | **Canonical** key; no duplicate competing keys | Single authoritative `synthesizedContext` on `executionMemory`; no shadow copies under undocumented alternate paths. | |
-
----
-
-## 4. MAIN input path
-
-| # | Check | How to validate | Pass |
-|---|--------|-----------------|------|
-| 4.1 | MAIN consumes `executionMemory.synthesizedContext` | Code path / logs: MAIN context build reads the artifact. | |
-| 4.2 | MAIN does **not** primarily rely on legacy assembled context | When structured path is active, dominance is not `webContextMarkdown`, raw Narrix markdown, or raw dumps alone. | |
-| 4.3 | Final prompt/messages to MAIN **reflect** synthesized payload | Diff or capture: sections/content align with structured synthesis output (e.g. built markdown from structured payload if that’s the bridge). | |
-| 4.4 | No **silent** fallback to old prompt construction | For runs that should pass this checklist, `mainContextSource === "legacy"` means the integration is wrong—fix upstream (request shape, pipeline, flags), not paper over it. Silent degradation without observable flags is unacceptable. | |
-
----
-
-## 5. Local-first behavior
-
-| # | Check | How to validate | Pass |
-|---|--------|-----------------|------|
-| 5.1 | Synthesized output **prioritizes** task/local/runtime facts over supporting web | Ordering and emphasis in structured local vs supporting sides; policy matches product intent. | |
-| 5.2 | Final answer **reflects** runtime-grounded facts first | Answer cites or follows execution/task memory before generic web summaries when both exist. | |
-| 5.3 | Not generic “public summary” when local should dominate | Deliberate fixture: strong local signal + web noise → answer anchored locally. | |
-| 5.4 | Supporting context stays **supportive** | Web/supporting material does not override or swamp local conclusions. | |
-
----
-
-## 6. Reporting and observability
-
-| # | Check | How to validate | Pass |
-|---|--------|-----------------|------|
-| 6.1 | Reports show whether **synthesis ran** | e.g. `synthesisEnabled`, pipeline/effective pipeline, or PRE phase completion in report payload. | |
-| 6.2 | Reports expose **detected template cores** | e.g. `detectedTemplateCores` in `metadata` / report mirror. | |
-| 6.3 | Reports show **`synthesizedContext` created** | e.g. `synthesizedContextPresent`. | |
-| 6.4 | Reports show **MAIN used synthesized input** | e.g. `mainContextSource === "synthesizedContext"` (and related flags if any). | |
-| 6.5 | If missing in reports, classify **reporting gap vs runtime failure** | Compare raw trace/logs to report: runtime correct but UI/report omits field → omission only; no artifact in memory but report says OK → failure. | |
-
----
-
-## 7. Pass criteria (single `runTask`)
-
-A single run **passes** only if **all** are true:
-
-1. **PRE synthesis ran** — synthesized-context PRE completed as intended.
-2. **Template cores were detected** — non-empty when the template defines detectable cores; empty case matches documented behavior for that template.
-3. **`executionMemory.synthesizedContext` exists** — structured artifact present before MAIN.
-4. **MAIN used synthesized payload** — `mainContextSource` (or equivalent) indicates synthesized path, not unintended legacy.
-5. **Observability shows that clearly** — synthesis, cores, artifact presence, and MAIN source are visible in metadata/traces/reports.
-6. **Final output is task-grounded and local-first** — answer quality matches sections 4–5 for the fixture used.
-
----
-
-## Quick reference (response `metadata`)
-
-When validating, confirm at least:
-
-- `detectedTemplateCores`
-- `synthesizedContextPresent`
-- `mainContextSource` (`"synthesizedContext"` vs `"legacy"`)
-- `synthesisEnabled` / `effectiveExecutionPipeline` as appropriate for your environment
-
-Treat `"legacy"` `mainContextSource` when a synthesized PRE ran and an artifact exists as a **red flag**: fix the caller (the remaining upstream package should converge on this checklist), not `ai-tasks`.

package/documenations/sessions/2026-06-08-subnets-model-resolution/CR-1-no-concrete-wire-in-graph-plans.md

@@ -1,93 +0,0 @@
-# CR-1 — No concrete wire models in compiled graph plans
-
-Status: **proposed**  
-Type: Change request  
-Owners: `@x12i/graphenix-plan-compiler`, `@exellix/graph-engine`, `@exellix/ai-tasks`  
-Filed: 2026-06-08  
-Session: [README](./README.md)
-
----
-
-## Summary
-
-Compiled executable node plans must store **profile/choice selections only**. They must **not** freeze concrete OpenRouter or gateway wire slugs in `resolvedInvocationSnapshot.modelId` or `AiConcreteModelSelection`.
-
-Concrete resolution happens **once at invoke time** inside ai-tasks / xynthesis / ai-skills — same boundary as xynthesis PRE/POST today.
-
----
-
-## Problem
-
-`overlayUnitModelOnRequest` prefers a pre-resolved snapshot over the authored selection:
-
-```typescript
-// ai-tasks/src/node-execution/resolveUnitModelSelection.ts
-if (snapshot && typeof snapshot.modelId === "string" && snapshot.modelId.trim()) {
-  wireValue = snapshot.modelId;  // e.g. "google/gemini-2.5-flash-lite"
-} else if (selection) {
-  wireValue = selectionToWireValue(selection);  // e.g. "cheap/default"
-}
-```
-
-When the compiler writes `resolvedInvocationSnapshot.modelId: "google/gemini-2.5-flash-lite"`:
-
-- Authoring shows `cheap/default` (correct).
-- Runtime overlay injects a **concrete slug** into `preActionModel` / `postActionModel` / `skillModel`.
-- Operators cannot tell whether failure is alias resolution or catalog lookup.
-- Catalog drift (retired slugs) breaks frozen plans even when profiles are still valid.
-
-This session's error slug may appear in the plan **even when input was `cheap/default`**.
-
----
-
-## Requirements
-
-### CR-1.1 — Compiler output
-
-- `executionUnits[].modelSelection` MUST be one of:
-  - `{ kind: "profileChoice", key: "cheap/default" }`
-  - `{ kind: "profile", profile: "cheap", choice: "default" }`
-- MUST NOT emit `{ kind: "concrete", ... }` / `AiConcreteModelSelection` in new plans (version gate).
-- MUST NOT emit `resolvedInvocationSnapshot.modelId` as a concrete provider/OpenRouter slug.
-
-### CR-1.2 — Optional compile-time preview (read-only)
-
-If compile needs a preview for UI, use a separate non-authoritative field, e.g.:
-
-```json
-"invocationPreview": {
-  "profileChoiceKey": "cheap/default",
-  "resolvedWireModelId": "google/gemini-2.5-flash-lite",
-  "phase": "preAction",
-  "resolverVersion": "ai-tasks/9.0.3"
-}
-```
-
-Preview MUST NOT be consumed by `overlayUnitModelOnRequest`.
-
-### CR-1.3 — ai-tasks runtime
-
-- `overlayUnitModelOnRequest`: ignore `resolvedInvocationSnapshot.modelId` when it looks like a concrete wire id (`isConcreteModelId`).
-- Prefer `modelSelection` profile/choice keys only.
-- Reject plans that only have concrete snapshot and no profile selection (validation error with path to unit).
-
-### CR-1.4 — Migration
-
-- Graphenix plan version bump (e.g. v2.2) documenting the rule.
-- One release: warn on concrete snapshot; next release: reject.
-
----
-
-## Acceptance criteria
-
-- [ ] Compiled plan for subnet PRE unit contains `modelSelection: { kind: "profileChoice", key: "cheap/default" }` and no concrete `modelId` in authoritative fields.
-- [ ] `overlayUnitModelOnRequest` passes `cheap/default` to `runTask`, not `google/gemini-2.5-flash-lite`.
-- [ ] `resolveInvocationPlan` at compile preview may still show resolved wire for UI — not stored on executable plan.
-- [ ] Existing graphs with concrete snapshots: migration script or re-compile from authoring.
-
----
-
-## Out of scope
-
-- Changing ai-profiles registry contents.
-- Banning concrete ids on ephemeral `RunTaskRequest.modelConfig` from direct API callers (see CR-2 for `skillModel` storage policy).

package/documenations/sessions/2026-06-08-subnets-model-resolution/CR-2-skillModel-profile-only-at-storage.md

@@ -1,88 +0,0 @@
-# CR-2 — `skillModel` profile/choice only at storage (align with PRE/POST)
-
-Status: **proposed**  
-Type: Change request  
-Owners: `@exellix/ai-tasks`, `@exellix/graph-engine`, `@x12i/graphenix-authoring-format`  
-Filed: 2026-06-08  
-Session: [README](./README.md)
-
----
-
-## Summary
-
-Today:
-
-| Slot | Storage rule |
-|------|----------------|
-| `preActionModel` | profile/choice only ✓ |
-| `postActionModel` | profile/choice only ✓ |
-| `skillModel` | profile/choice **or** concrete wire id ✗ |
-
-There is no catalog field called "main model" (skill catalog stores no model — verified). The issue is **runtime/graph storage**: allowing **concrete** `skillModel` in graph JSON, fixtures, and plans freezes vendor slugs in orchestration data, separate from Catalox skill rows.
-
-**Change:** `skillModel` and MAIN `llmCall.model` MUST be profile/choice keys at storage and in graph plans. Concrete wire ids are produced only at invoke resolution (ai-tasks → ai-skills), identical to how xynthesis resolves PRE/POST.
-
----
-
-## Problem
-
-- `BREAKING-CHANGES.md` (8.4+) still documents concrete ids on `skillModel` as accepted.
-- Fixtures use concrete MAIN models, e.g. `skillModel: "openrouter/x-ai/grok-4.1-fast"`.
-- Operators conflate "MAIN model" with a durable catalog property; it is only the **`skillModel` runtime slot** for the `mainSkill` execution unit.
-
-Desired model:
-
-- **Suggested profile** on skill catalog row (FR-1) → default hint for graph authoring.
-- **Per-node override** → `skillModel: "pro/default"` in plan.
-- **Invoke** → ai-tasks resolves to gateway wire id once before `runSkill`.
-
----
-
-## Requirements
-
-### CR-2.1 — Validation
-
-- `validateRunTaskModelReferences` / `resolveRunTaskModelReferences`: reject concrete ids on `skillModel` and MAIN `llmCall.model` with `XYNTHESIS_CONCRETE_MODEL_REJECTED` equivalent: `SKILL_MODEL_CONCRETE_REJECTED`.
-- Message: use profile/choice (e.g. `pro/default`, `cyber/default`).
-
-### CR-2.2 — Resolution unchanged at invoke
-
-- `prepareMainSkillModelConfigForInvoke` continues to resolve profile → gateway wire (`openrouter/...`) immediately before ai-skills.
-- No behavior change for correctly authored graphs.
-
-### CR-2.3 — Graph authoring
-
-- Node model picker for MAIN unit: profile/choice only (same UX as PRE/POST).
-- Remove concrete model picker from persisted graph JSON.
-
-### CR-2.4 — Docs and fixtures
-
-- Update `ai-tasks/README.md`, `BREAKING-CHANGES.md`, test fixtures to profile-only `skillModel`.
-- Remove "concrete ids on MAIN only" exception language.
-
----
-
-## Acceptance criteria
-
-- [ ] `skillModel: "openrouter/x-ai/grok-4.1-fast"` fails validation at `runTask` entry.
-- [ ] `skillModel: "pro/default"` resolves and invokes successfully.
-- [ ] `professional-answer` Catalox row still has **no** model field (only optional `suggestedProfile` per FR-1).
-- [ ] Graph-engine passes profile keys on `mainSkill` units.
-
----
-
-## Migration
-
-| From | To |
-|------|-----|
-| `skillModel: "anthropic/claude-sonnet-4"` | `skillModel: "pro/default"` (or appropriate profile) |
-| `skillModel: "openrouter/x-ai/grok-4.1-fast"` | `skillModel: "cyber/default"` or explicit profile choice |
-
-Provide `resolveInvocationPlan` mapping table in migration notes for common concrete → profile mappings.
-
----
-
-## Non-goals
-
-- Removing invoke-time resolution to concrete ids (still required for ai-gateway).
-- Changing Optimixer catalog fields on skill rows.

package/documenations/sessions/2026-06-08-subnets-model-resolution/CR-3-reject-concrete-models-in-catalog-rows.md

@@ -1,76 +0,0 @@
-# CR-3 — Reject concrete model ids in skill / funcx / xynthesis catalog rows
-
-Status: **proposed (guardrail)** — verified compliant today  
-Type: Change request  
-Owners: `@exellix/ai-skills`, `@x12i/funcx`, `@exellix/xynthesis`  
-Filed: 2026-06-08  
-Session: [README](./README.md)
-
----
-
-## Summary
-
-**Verified 2026-06-08:** skill / funcx **content** catalogs do **not** store models today. This CR is a **preventive guardrail** (provision lint + schema), not remediation of a current data bug.
-
-Do not confuse with:
-
-- **Runtime** `modelConfig` / graph `modelSelection` (orchestrator data — see CR-1, CR-2).
-- **`@x12i/ai-tools` models catalog** (npm package used by funcx for slug validation — unrelated to Catalox skill rows).
-
-Catalog rows (Catalox `ai-skills`, funcx function defaults, xynthesis sidekick seeds) must **never** store a concrete LLM wire model as the authoritative model for a skill or action.
-
-Allowed:
-
-- `suggestedProfile` / `modelPick` as **`profile/choice`** (e.g. `pro/default`, `balanced/default`).
-- Optimixer sizing fields (output intent, reasoning effort catalog default, task type).
-
-Forbidden:
-
-- `model`, `modelId`, `mainModel`, `defaultModel` with values like `google/gemini-2.5-flash-lite`, `gpt-4o-mini`, `openrouter/...`.
-
----
-
-## Current state (mono-repo audit 2026-06-08)
-
-| Catalog | Concrete model stored? | Profile suggestion? |
-|---------|------------------------|---------------------|
-| `ai-skills` Catalox (`AI_SKILLS_CATALOG_ITEMS`) | **No** ✓ | **No** (gap → FR-1) |
-| `xynthesis` `model-routing.json` | **No** ✓ (output sizing only) | N/A |
-| `xynthesis` Catalox seed (`modelPick`) | **No** ✓ | `balanced/default`, etc. |
-| funcx built-in / content catalog | Audit consumer + funcx repo | TBD |
-
-`professional-answer` row contains only Optimixer metadata — **compliant** with CR-3.
-
----
-
-## Requirements
-
-### CR-3.1 — Schema validation at provision time
-
-- ai-skills `provision-ai-skills-catalog`: reject rows with `model`, `mainModel`, `defaultModel`, or concrete-pattern `modelId`.
-- xynthesis seed validators: allow only `modelPick` matching `profile/choice` regex.
-- funcx catalog linter: same rule for function `defaults.model`.
-
-### CR-3.2 — Runtime must not read catalog model for invoke
-
-- ai-skills `runSkill` model comes **only** from `RunSkillRequest.modelConfig.model` (set by orchestrator).
-- funcx `run()` / sidekick: model from request or `modelPick` profile resolved at invoke — never a frozen slug from catalog body.
-
-### CR-3.3 — Naming ban
-
-- Disallow field names `mainModel`, `defaultModel`, `skillModel` on catalog `data` objects (reserved for runtime request shape).
-
----
-
-## Acceptance criteria
-
-- [ ] Provision script fails if a skill row includes `model: "google/..."`.
-- [ ] `professional-answer` provision unchanged (Optimixer-only).
-- [ ] Documentation lists allowed catalog model fields: `suggestedProfile` only (see FR-1).
-
----
-
-## Related
-
-- FR-1 adds the **positive** allowed field.
-- CR-2 ensures graph/runtime `skillModel` is also profile-only at storage.

package/documenations/sessions/2026-06-08-subnets-model-resolution/FR-1-suggested-profile-in-catalogs.md

@@ -1,96 +0,0 @@
-# FR-1 — Suggested profile on skill and funcx catalog rows
-
-Status: **proposed**  
-Type: Feature request  
-Owners: `@exellix/ai-skills`, `@x12i/funcx`, `@exellix/xynthesis`  
-Filed: 2026-06-08  
-Session: [README](./README.md)
-
----
-
-## Summary
-
-Add an optional **`suggestedProfile`** (or reuse xynthesis **`modelPick`**) on catalog rows: a single **`profile/choice`** string that recommends which ai-profiles tier fits this skill or sidekick action.
-
-This is a **hint for authoring and studio UIs** — not an invoke-time default that bypasses the orchestrator.
-
----
-
-## Motivation
-
-- Operators want "what model tier fits `professional-answer`?" without storing concrete slugs.
-- Graph nodes should start from `suggestedProfile` when the author does not override `skillModel`.
-- Aligns with CR-3 (no concrete models in catalog) while supporting discoverability.
-
----
-
-## Proposed shape
-
-### ai-skills Catalox row
-
-```json
-{
-  "skillKey": "professional-answer",
-  "suggestedProfile": "pro/default",
-  "optimixerReasoningEffort": "low",
-  "optimixerOutputIntent": { "mode": "relative", "expectedVisibleTokens": 1200 }
-}
-```
-
-### xynthesis sidekick seed (already similar)
-
-```json
-{
-  "defaults": {
-    "modelPick": "balanced/default",
-    "outputMode": "structured"
-  }
-}
-```
-
-Standardize naming in docs: **`suggestedProfile`** for skills, **`modelPick`** for xynthesis actions (alias in UI).
-
----
-
-## Behavior
-
-| Layer | Behavior |
-|-------|----------|
-| **Catalog** | Store `suggestedProfile` only; validate `profile/choice` via `@x12i/ai-profiles`. |
-| **Studio / graph authoring** | New node MAIN unit pre-fills `modelSelection` from skill's `suggestedProfile`. |
-| **runTask / runSkill** | Orchestrator MUST still send `modelConfig.skillModel` (or plan unit selection). Catalog hint is **not** a silent default at invoke. |
-| **diagnoseSkillInCatalog** | Return `suggestedProfile` in diagnostic payload for tooling. |
-
----
-
-## API sketch (ai-skills)
-
-```typescript
-type AiSkillsCatalogItemSpec = {
-  skillKey: string;
-  // ...
-  suggestedProfile?: string; // e.g. "pro/default"
-};
-```
-
-Export helper:
-
-```typescript
-function assertSuggestedProfile(value: string): void;
-```
-
----
-
-## Acceptance criteria
-
-- [ ] `professional-answer` can ship with `suggestedProfile: "pro/default"` (product choice).
-- [ ] Provision rejects invalid profile keys and concrete slugs.
-- [ ] Invoke without `skillModel` still fails fast (no hidden catalog default).
-- [ ] Studio can list skills with suggested tier for graph palette.
-
----
-
-## Non-goals
-
-- Auto-picking model at `runSkill` without orchestrator `modelConfig`.
-- Storing multiple ranked profiles (future: `suggestedProfiles[]` if needed).

package/documenations/sessions/2026-06-08-subnets-model-resolution/FR-2-graph-engine-failure-phase-attribution.md

@@ -1,92 +0,0 @@
-# FR-2 — Graph-engine failure phase attribution (PRE vs MAIN vs POST)
-
-Status: **proposed**  
-Type: Feature request  
-Owners: `@exellix/graph-engine`  
-Filed: 2026-06-08  
-Session: [README](./README.md)
-
----
-
-## Summary
-
-When `runTask` fails, graph-engine should surface **`phase`** and **`stage`** from `@exellix/ai-tasks` `RunTaskExecutionError` (or root cause), not only `skillKey`.
-
-This session's confusion: error message referenced `skillKey=professional-answer` while the root cause was likely **PRE synthesis** (`cheap/default` → funcx catalog), not MAIN skill invoke.
-
----
-
-## Problem
-
-Current wrapper shape (observed):
-
-```text
-runTask failed (skillKey=professional-answer nodeId=node:inbound-reachability graphId=graph:subnets-analysis): Unknown model "google/gemini-2.5-flash-lite" ...
-```
-
-ai-tasks native format includes phase when known:
-
-```text
-runTask failed (phase=pipeline_pre skillKey=...): ...
-```
-
-Graph-engine omits `phase=`, so operators assume **MAIN / professional-answer model** is wrong.
-
----
-
-## Requirements
-
-### FR-2.1 — Error envelope
-
-Node execution error SHOULD include:
-
-```json
-{
-  "skillKey": "professional-answer",
-  "graphId": "graph:subnets-analysis",
-  "nodeId": "node:inbound-reachability",
-  "phase": "pipeline_pre",
-  "stage": "pre-synthesis",
-  "rootMessage": "Unknown model \"google/gemini-2.5-flash-lite\" ...",
-  "rootCode": "MISSING_ENV",
-  "modelConfig": {
-    "preActionModel": "cheap/default",
-    "skillModel": "pro/default",
-    "postActionModel": "cheap/default"
-  },
-  "failureClassification": { "role": "cause", "event": "provider_invoke" }
-}
-```
-
-### FR-2.2 — Propagation
-
-- Parse `RunTaskExecutionError.details.phase` when present.
-- Fall back to heuristic on `rootMessage` (funcx catalog → `pipeline_pre` or `pipeline_post`; gateway → `main_skill`).
-
-### FR-2.3 — UI copy
-
-- Display: **"PRE synthesis failed"** vs **"Skill invoke failed"** based on `phase`.
-- Do not show "professional-answer model error" when `phase !== main_skill`.
-
----
-
-## Acceptance criteria
-
-- [ ] PRE funcx catalog failure shows `phase: "pipeline_pre"` in graph-engine node error JSON.
-- [ ] MAIN gateway failure shows `phase: "main_skill"`.
-- [ ] Same `skillKey` on wrapper; phase disambiguates.
-
----
-
-## Reference (ai-tasks)
-
-- `RunTaskFailurePhase`: `pipeline_pre`, `main_skill`, `pipeline_post`, `model-resolution`, …
-- `formatRunTaskExecutionMessage` in `ai-tasks/src/errors/runTaskExecutionError.ts`
-- `classifyRunTaskFailure` in `ai-tasks/src/observability/classifyRunTaskFailure.ts`
-
----
-
-## Non-goals
-
-- Changing ai-tasks error types (consume as-is).
-- Resolving catalog issues (see [INVESTIGATION-original-bug.md](./INVESTIGATION-original-bug.md)).