← get-fableCONTENT HISTORYWHAT CHANGED · RULE-BASED ANALYSIS
Update to get-fable
Snapshot Sep 30, 2026 · 23:14 UTC · version 1.5.1
Collection source: not recorded for this historical snapshot.
First saved snapshot
No earlier snapshot is available to establish a change.
Compare saved observations
Download comparison JSONFull technical diff · 0 changed fields
Full snapshot data
{
"description": "Launch, manage, and verify live applications across CLI binaries, web servers, TUIs, Electron apps, and background daemons with readiness probes and clean teardown. Use when starting development servers, executing live smoke tests, testing interactive CLI binaries, or driving runtime smoke verification — even if the user does not explicitly say \"fable-run\" (e.g. \"start the dev server\", \"launch the app\", \"test the running CLI\", \"smoke test the web app\"). Do NOT use for static analysis or unit testing without a running process (use fable-verify).",
"included_files": [
{
"relative_path": "agents/openai.yaml",
"size_in_bytes": 359
},
{
"relative_path": "evals/scenarios.json",
"size_in_bytes": 3991
},
{
"relative_path": "examples/live-server-smoke-check.md",
"size_in_bytes": 293
},
{
"relative_path": "references/process-lifecycle-and-readiness.md",
"size_in_bytes": 2234
},
{
"relative_path": "references/runtime-process-management.md",
"size_in_bytes": 1432
},
{
"relative_path": "skill.package.json",
"size_in_bytes": 462
},
{
"relative_path": "templates/runtime-smoke-probe.template.md",
"size_in_bytes": 642
}
],
"name": "fable-run",
"skill_md_contents": "---\nname: fable-run\ndescription: \"Launch, manage, and verify live applications across CLI binaries, web servers, TUIs, Electron apps, and background daemons with readiness probes and clean teardown. Use when starting development servers, executing live smoke tests, testing interactive CLI binaries, or driving runtime smoke verification — even if the user does not explicitly say \\\"fable-run\\\" (e.g. \\\"start the dev server\\\", \\\"launch the app\\\", \\\"test the running CLI\\\", \\\"smoke test the web app\\\"). Do NOT use for static analysis or unit testing without a running process (use fable-verify).\"\nversion: 1.3.0\npack: system\ninputs:\n - app_target\nrequires:\n - built_artifact\nproduces:\n - runtime_evidence\n - smoke_proof\ngates:\n - process_clean_exit\n - status_200\nfallback: fable-recover\nmutatesWorkspace: false\nparallelSafe: false\nneural_links:\n precursors:\n - fable-dataviz\n - fable-execute\n continuations:\n - fable-verify\n - fable-release\n lateral_peers:\n - fable-verify\n recovery: fable-recover\n---\n\n# Fable Run\n\nExecute the real artifact in a bounded environment and collect runtime evidence without confusing \"process started\" with \"application works.\"\n\n## Mission\nRuntime work needs lifecycle ownership: exact command/artifact, working directory, environment, ports, readiness criteria, output bounds, timeout, and cleanup.\n\nA server PID, HTTP 200 from the wrong process, or CLI exit 0 that never exercised the feature is not sufficient proof.\n\n## Activate When\n- a server/service must run to verify behavior;\n- a built/published CLI or executable needs a smoke test;\n- browser/runtime integration requires a live process;\n- a runtime path differs materially from unit-test/source execution;\n- verification needs empirical entrypoint/lifecycle evidence.\n\n## Do Not Activate When\n- unit/integration tests can prove behavior without a persistent live process (`fable-verify`);\n- code still needs implementation (`fable-execute`);\n- repeated runtime failure/staleness needs diagnosis (`fable-recover`);\n- launching the process would cause an unauthorized/destructive external side effect.\n\n## Runtime Classification\n| Target | Important controls |\n| --- | --- |\n| one-shot CLI | cwd/env/args, exit, stdout/stderr, side effects |\n| HTTP server | port ownership, readiness, health vs feature probe, cleanup |\n| worker/daemon | startup readiness, queue/input fixture, termination |\n| browser app | server URL, browser readiness, console/network errors |\n| packaged binary | exact artifact/version/path, clean environment |\n| multi-service | dependency startup order, ports, teardown, correlation |\n\n## Protocol\n### Stage 1 — Identify the exact artifact\nRecord:\n- command/binary path;\n- version/hash/build if relevant;\n- cwd;\n- required environment/config;\n- expected process type;\n- safe input/probe;\n- destructive/external side effects to avoid.\n\nDo not assume `foo` on PATH is the artifact just built—resolve it when identity matters.\n\n### Stage 2 — Establish resource ownership\nBefore launch determine:\n- requested/available port;\n- whether an existing process owns it;\n- temp directories/files;\n- child-process behavior;\n- timeout/budget;\n- cleanup method.\n\nNever kill an unrelated process merely to acquire a preferred port.\n\n### Stage 3 — Launch with bounded observation\nCapture PID/process handle, stdout/stderr, startup errors, and timestamps. Use output/timeout limits so a noisy/hung service cannot consume unbounded resources.\n\n### Stage 4 — Distinguish startup from readiness\nA successful spawn only means the OS accepted the process.\n\nReadiness may require:\n- port accepting connections;\n- health endpoint with expected payload;\n- dependency initialization complete;\n- CLI command reaches expected branch;\n- browser page loads without fatal console/runtime errors.\n\nUse a bounded readiness loop with backoff rather than a fixed arbitrary sleep when possible.\n\n### Stage 5 — Probe the behavior that matters\nHealth 200 proves health only. If the changed feature is `/checkout`, probe the smallest safe checkout behavior/contract rather than concluding from `/healthz` alone.\n\nRecord request/input and relevant response/side effect.\n\n### Stage 6 — Detect wrong/stale process\nIf output contradicts source/build expectations, check:\n- resolved executable/import path;\n- process start time;\n- port owner PID;\n- build/artifact hash;\n- cwd/env;\n- old server still running.\n\nRoute repeated ambiguity to recovery before changing product logic.\n\n### Stage 7 — Terminate cleanly\nStop only processes/resources owned by this run. Wait for clean exit where feasible, escalate termination only within the owned process tree, and remove temporary resources.\n\n### Stage 8 — Record runtime evidence narrowly\nState what the run proves: entrypoint launches, endpoint behavior observed, shutdown clean, etc. Hand broader correctness to `fable-verify`.\n\n## Decision Rules\n- Port conflict with unknown process → choose another safe port or inspect owner; do not indiscriminately kill it.\n- Spawn success without readiness → keep waiting/probing within budget, not PASS.\n- Health success without changed-feature probe → only health claim passes.\n- Fixed sleep for readiness is weaker than bounded condition polling; prefer observable readiness.\n- Runtime output unchanged after source change → prove artifact/process identity before another code mutation.\n- One-shot CLI that intentionally exits nonzero can still be a valid tested error path; compare exit/output to expected contract rather than requiring 0 universally.\n- External production-like side effect requires explicit safe scope/authorization; prefer local fixture/sandbox when available.\n- Background processes must have ownership and cleanup even if the test itself fails.\n\n## Invariants\n- Exact runtime artifact/process identity is knowable when used as evidence.\n- No unrelated process is killed.\n- Spawn, readiness, behavior, and shutdown are separate claims.\n- Runtime probes are bounded by time/output/resources.\n- Owned background resources are cleaned on success and failure.\n- Evidence does not claim more than the actual probe exercised.\n\n## Failure Taxonomy\n### Spawn failure\nExecutable missing, permission/config/startup error. Inspect command/artifact/env before retry.\n\n### Readiness failure\nProcess alive but service never becomes usable. Capture startup logs/dependencies and diagnose.\n\n### Wrong-process evidence\nPort/path points to an older/unrelated process. Resolve identity, do not mutate product.\n\n### Feature probe failure\nRuntime is ready but target behavior is wrong. Return to verify/execute/recover based on clarity.\n\n### Hang/leak\nProcess or child does not terminate. Inspect lifecycle/cleanup; force only owned tree within bounds.\n\n### Environmental mismatch\nBehavior depends on cwd/env/OS/runtime version. Record and reconcile rather than treating as product fact universally.\n\n## Anti-Patterns\n- `sleep 5 && curl /healthz` as universal runtime proof;\n- assuming PID created means ready;\n- using 200 from health endpoint to prove unrelated feature;\n- killing whatever owns port 3000;\n- leaving server running after failure;\n- testing a PATH-installed old binary instead of candidate artifact;\n- ignoring stderr because process stayed alive;\n- unbounded log capture or polling;\n- performing real destructive transactions for a smoke test without need.\n\n## Runtime Packet\n```text\nArtifact/command/version:\nCWD/env/config:\nOwned resources/PID/port:\nReadiness condition/result:\nBehavior probe/result:\nStdout/stderr highlights:\nArtifact/process identity checks:\nTermination/cleanup:\nWhat this proves:\nWhat remains for verify:\n```\n\n## Completion Criteria\nRuntime execution completes when:\n- exact candidate process/artifact was launched under known context;\n- readiness was observed, not assumed;\n- relevant behavior was probed or evidence scope is explicitly limited;\n- stale/wrong process ambiguity is resolved;\n- owned processes/resources are cleaned;\n- evidence is handed to verification without overclaiming.\n\n## Progressive Resources\n- Deep guide: `references/process-lifecycle-and-readiness.md`\n- Existing protocol: `references/runtime-process-management.md`\n- Example: `examples/live-server-smoke-check.md`\n"
}SHA-256 of public snapshot: d5001db5e528f84914fea21ea6cbd787b359f0842d48b2dd67a69c9af622e224