@tdk-landscape/tdk-cli-core 1.3.53 → 1.3.54

package/openspec/changes/prioritized-cold-start/specs/on-demand-resource-startup/spec.md

@@ -1,98 +0,0 @@
-# Spec Delta
-
-## Purpose
-
-Lets a resource opt out of `tdk up`'s normal sequential bring-up and instead start on its own first request, so one request against a large landscape doesn't wait behind every other resource's startup.
-
-## ADDED Requirements
-
-### Requirement: Deferred Start Opt-In
-
-A resource with a `sablier` manifest block SHALL be able to mark itself deferred for the current `tdk up` run. A deferred resource's image SHALL still be built during `tdk up`, but its container SHALL NOT be started as part of `tdk up`'s normal bring-up sequence.
-
-#### Scenario: Deferred resource is not started during tdk up
-
-- **WHEN** `tdk up` runs a landscape containing a resource with deferred start enabled
-- **THEN** that resource's image build completes during the run, under the image tag its compose service declares, so its first request can start it without building
-- **AND** the resource's container is not started, and `tdk up` does not wait on it to become healthy before finishing bring-up of the rest of the landscape
-
-#### Scenario: Non-opted-in resource is unaffected
-
-- **WHEN** `tdk up` runs a landscape containing a resource with no `sablier` block, or a `sablier` block without deferred start enabled
-- **THEN** that resource is built and started as part of `tdk up`'s normal dependency-graph sequencing, exactly as before this change
-
-### Requirement: Deferred Resource Stays Discoverable Before Its First Start
-
-A deferred resource's Traefik route SHALL be registered and routable regardless of whether its container has ever been created, so the first request to it can be received and acted on rather than returning "no route" or a connection error.
-
-#### Scenario: Route exists before first start
-
-- **WHEN** `tdk up` finishes bring-up of a landscape containing a deferred resource that has never been started this session
-- **THEN** a request to that resource's route reaches Traefik and is recognized as targeting a known, deferred resource, rather than returning "no route" or a connection error
-
-#### Scenario: Route still resolves after the resource has run and stopped
-
-- **WHEN** a deferred resource has run at least once this session and its container is now stopped
-- **THEN** a request to that resource's route still reaches Traefik and is recognized as targeting that resource, using the same or an equivalent route as before it ever ran
-
-### Requirement: First Request Triggers And Prioritizes Startup
-
-The first request to a deferred resource's route SHALL start that resource's container and SHALL cause the resource to be prioritized ahead of the landscape's normal remaining bring-up order, rather than waiting for that order to reach it naturally.
-
-#### Scenario: Request during a large, in-progress tdk up
-
-- **WHEN** a request is made to a deferred resource's route while `tdk up` is still bringing up other, unrelated resources elsewhere in the landscape
-- **THEN** the deferred resource is started and reaches a healthy state without waiting for the rest of the landscape's bring-up to complete first
-
-#### Scenario: Request after tdk up has finished
-
-- **WHEN** a request is made to a deferred resource's route after `tdk up` has finished bringing up the rest of the landscape
-- **THEN** the deferred resource starts immediately in response to that request
-
-### Requirement: Waking A Resource Also Wakes Its Required Dependencies
-
-Waking a deferred resource SHALL also wake any of its required startup dependencies (the same dependencies already used to sequence Tilt's own bring-up, e.g. its database or messaging broker) that are not currently running, and SHALL wait for each to be ready before evaluating the resource's own health.
-
-#### Scenario: Deferred resource depends on a cold database
-
-- **WHEN** a request wakes a deferred resource whose required dependencies include another resource that is not currently running
-- **THEN** that dependency is also started as part of the same wake, and the requesting resource's health checks are not evaluated against a still-cold dependency
-
-#### Scenario: Unrelated resource is not woken
-
-- **WHEN** a request wakes a deferred resource
-- **THEN** resources that are not among its required startup dependencies are not started as a side effect of that wake
-
-### Requirement: A Waking Request Waits For Health, Not Just Start
-
-A request that triggers a deferred resource's startup SHALL be held until the resource passes its health check, until a bounded hold window elapses, or until a bounded timeout elapses, rather than being answered as soon as the container process starts. The caller SHALL always receive a response; the connection SHALL NOT be dropped silently.
-
-#### Scenario: Client receives the real response
-
-- **WHEN** a request wakes a deferred resource that becomes healthy within the hold window
-- **THEN** the client's request is held and then answered by the resource once it is healthy, rather than receiving an immediate "starting" response with no real answer
-
-#### Scenario: Startup outlasts the hold window
-
-- **WHEN** a request wakes a deferred resource that is still not healthy when the hold window ends (e.g. the Docker daemon is saturated by a full `tdk up` bring-up)
-- **THEN** the request is answered with `503` and a `Retry-After` header while the start continues in the background
-- **AND** a retry, or any other request that arrives meanwhile, joins that same start instead of starting the resource again, and is answered by the resource once it is healthy
-
-#### Scenario: Startup exceeds the timeout
-
-- **WHEN** a deferred resource does not become healthy within its configured wake timeout
-- **THEN** the held request fails with a clear timeout error rather than hanging indefinitely
-
-### Requirement: Deferred Status Is Reported Distinctly From Failure
-
-`tdk up` and `tdk doctor` SHALL report a deferred, not-yet-started resource as intentionally deferred, and SHALL NOT report it the same way as a stalled or failed resource.
-
-#### Scenario: tdk up summary
-
-- **WHEN** `tdk up` finishes bring-up of a landscape containing deferred resources that have not yet received a request
-- **THEN** the summary output lists those resources as deferred rather than omitting them or listing them as pending/stalled
-
-#### Scenario: tdk doctor
-
-- **WHEN** `tdk doctor` runs against a landscape containing a deferred, not-yet-started resource
-- **THEN** it does not flag that resource as unhealthy or stuck solely because it has not started

package/openspec/changes/prioritized-cold-start/tasks.md

@@ -1,69 +0,0 @@
-# Tasks
-
-## 1. Preflight checks
-
-- [x] 1.1 ~~Confirm whether `dc_resource(..., auto_init=False)` pre-creates the underlying container~~ — **Done, confirmed empirically 2026-09-26** against the installed Tilt `v0.37.7`: a throwaway `dc_resource(auto_init=False)` produces no container object at all (`docker ps -a` empty for it, `uiresource.status.runtimeStatus`/`updateStatus` stay `none`) until triggered; `tilt trigger <name>` then creates and starts it in one call. Recorded under design D2/D3. No further verification needed on this point.
-- [x] 1.2 ~~Confirm whether the vendored `sablierapp/sablier` version supports a webhook/hook callable on container start~~ — **Done, confirmed 2026-09-26** by reading the v1.18 docs (`sablierapp.dev/v1.18`, version-matched to the vendored `1.18.0`): Sablier has no hook/webhook system at all — it's pull-based (the reverse-proxy plugin queries Sablier's status API per request; the "blocking strategy" page describes exactly this loop). Recorded under design D3: the wake gateway is a self-written component regardless, not a Sablier extension point.
-- [x] 1.3 ~~Confirm the Tilt HTTP trigger API request shape~~ — **Superseded, 2026-09-26**: design D3 now prefers shelling out to the `tilt trigger <resource>` CLI (proven working end-to-end in the 1.1 probe) over the undocumented internal HTTP API, so no request-shape verification is needed.
-- [x] 1.4 ~~Confirm how Traefik's Docker provider and file provider behave when both eventually define a router for the same resource name~~ — **Done, confirmed empirically 2026-09-26** with an isolated Traefik + Docker probe (torn down after): same-named `@file` and `@docker` routers coexist without conflict, but at equal priority **the file-provider router wins** even once the real container is healthy (a test request got `502` from the stale file-routed backend, not the working docker-routed one). Giving the file-provider entry a fixed low priority (`1`) while the docker-label path keeps its normal computed priority fixed this — the docker route then won automatically as soon as it existed. **Conclusion: the generated file-provider entry (task 4.2) must set an explicit low priority; do not rely on Traefik "preferring" one router on its own.**
-- [x] 1.5 ~~Confirm whether `tilt trigger <resource>` cascades to a `depends_on` dependency that is itself `auto_init=False`~~ — **Done, confirmed empirically 2026-09-26** with the same isolated-probe technique as 1.1 (two `dc_resource(auto_init=False)` services, one `depends_on` the other with `condition: service_healthy`, fully torn down after): Tilt parses the compose `depends_on` and adds its own wait, but triggering only the dependent resource leaves it parked at `runtimeStatus: pending`, `status.waiting = {on: [dependency], reason: "waiting-for-dep"}` indefinitely — Tilt does not auto-trigger the dependency. Triggering the dependency separately immediately cleared the wait and let the dependent resource build and start. **Conclusion: the wake gateway (task 4.3) must explicitly `tilt trigger` every `depends_on` dependency itself; the cascade cannot be relied on.**
-
-## 2. Manifest schema (D1)
-
-- [x] 2.1 Add `deferStart` (boolean, default `false`) to the `sablier` schema block in `engine/topologies/tilt/manifest/schema.star` and to the `sablier` type in `cli/src/types/index.ts`. Verify with a schema validation test asserting a manifest with `sablier: {enable: true, deferStart: true}` passes validation and one with `deferStart` set but `enable` absent/false fails with a clear error (deferStart requires enable). **Done**: added the schema field, a `_validate_cross_field` rule in `validator.star`, and `tests/tilt-engine/test_sablier_defer_start.py` (7 cases, all passing via `tilt alpha tiltfile-result`).
-- [x] 2.2 Update the `sablier` entry in `cli/src/utils/resource-features.ts` to document `deferStart`. Verify by running the existing feature-description test/lint that covers this file, if any, or a manual `tdk resource --help`-style check that the new field appears. **Done**: description and `generator_file`/`output_file` updated; no dedicated test file existed for this file, verified with `npm run typecheck` (clean).
-
-## 3. Per-resource deferred auto_init (D1)
-
-- [x] 3.1 Add a `resource_defers_start(manifest)` helper (co-located with the other manifest-derived helpers used by `apply_compose_resource_registration.star`) that reads the resolved `sablier.enable`/`sablier.deferStart` for a manifest. Verify with a unit test covering: no `sablier` block, `enable: false`, `enable: true` without `deferStart`, and `enable: true, deferStart: true`. **Done**: added at `apply_compose_resource_registration.star:117` (no leading underscore — confirmed via a throwaway probe that Tilt's `load()` genuinely rejects underscore-prefixed names, so a directly-loadable unit test needed a non-underscored name); 7 cases added to `test_sablier_defer_start.py`, all passing.
-- [x] 3.2 Change `_register_single_resource` (the actual primary `dc_resource` call at `apply_compose_resource_registration.star:238` — not `_register_replicas`, which only ever fires for extra replicas beyond the first) to resolve `auto_init` per-resource as `auto_init_apps and not resource_defers_start(config['manifest'])`, threading that same `effective_auto_init` into `dc_resource`, `_register_run_only_resource`, and `_register_replicas` alike; `docker_build` is unaffected since it has no `auto_init` parameter in this codebase, so the image still builds regardless. `_build_resource_config` now also carries `'manifest': manifest` so this is available. **Done and code-reviewed**; verified indirectly via 3.1's predicate tests plus reading every call site — a full live `dc_resource` integration test is deferred to task 7.2's real `tdk-erp-system` run rather than duplicated here with a synthetic project.
-- [ ] 3.3 Confirm end to end that a `deferStart` resource genuinely produces no container object after `tdk up` finishes (per 1.1's confirmed finding, this is expected, not a bug) — `docker ps -a` shows nothing for it — and that its config-gen and image build still completed. Folded into task 7.2's real `tdk-erp-system` run rather than a separate synthetic project.
-
-## 4. Static route for never-created resources (D2, D4)
-
-- [x] 4.1 Add `--providers.file.directory=/etc/traefik/dynamic` to the standalone Traefik command list in `engine/topologies/platform/docker/compose/traefik_standalone.star`, plus a mounted directory for generated dynamic-config files. **Done**: also added `--providers.file.watch=true`, a `./traefik-dynamic:/etc/traefik/dynamic:ro` mount (`PlatformDockerConstants.TRAEFIK_DYNAMIC_DIR_REL`), and the `wake-gateway` service itself (built from the new `engine/assets/docker/wake-gateway/`, auto-vendored into every generated project since `engine/` is copied wholesale — confirmed by reading `cli/src/generator/template-engine.ts`'s `TDK_EXTENSION_DIRS`). Verified for real: `docker compose up -d --build` on the generated compose brought up `traefik`+`sablier`+`wake-gateway` together (only a host port-80 conflict with the already-running real landscape, not a config defect); `test_standalone_compose_enables_file_provider_and_wake_gateway` covers it as a repeatable test.
-- [x] 4.2 Generate a file-provider dynamic-config entry for each `deferStart` resource, reusing the exact same router rule/middleware values the Docker-label path already computes for that resource, pointed at the wake gateway's address instead of the resource's own port, with a fixed low priority (`1`). **Done**: `engine/topologies/platform/docker/networking/traefik_static_routes.star`, config travels via an injected `headers` middleware (`X-Wake-Resource`/`X-Wake-Container`/`X-Wake-Deps`/`X-Wake-Proxy-Port`) rather than the path, so the real request path reaches the backend unchanged; `X-Wake-Container`/each dependency's container name follow Compose's `<project>-<service>-1` convention (confirmed against the live `analytics-autogenerated-data-governance-api-1` container). `test_traefik_static_wake_route.py` (3 cases) verifies the rule matches the Docker-label `-project` router, the priority is `1` and lower than the computed one, and the headers carry container names correctly.
-- [x] 4.3 Stand up the wake gateway referenced by 4.2 that triggers a cold resource and its dependencies, then holds the request and proxies it through once healthy. **Done**: `engine/assets/docker/wake-gateway/` (`decide.ts` pure decision logic + 9 `bun test` cases, `server.ts` the real Bun HTTP server, `Dockerfile`). Full real end-to-end verification via three disposable probes (all torn down): (a) confirmed `tilt trigger` from inside a container needs the host's `~/.tilt-dev` token directory mounted read-only — without it, every trigger call fails with `(403): invalid session token` even though the Tilt port is reachable; (b) confirmed and fixed a Bun `URL.host` setter bug (`target.host = "name:port"` silently kept the original port; fixed by setting `.hostname`/`.port` separately) and a header-forwarding bug (`fetch` rejected the raw incoming `Host`/`X-Wake-*` headers; fixed by building a clean header set); (c) with both fixes, a real cold `traefik/whoami` container (both "exited" and fully "absent" states) was woken, became healthy, and a request was correctly proxied through with its original path intact, in ~10-29s.
-- [x] 4.4 Confirm end to end that 4.2's fixed low priority actually hands traffic back to the real container once it exists. **Done** — this is exactly what task 1.4's probe verified (recorded there): at equal priority the file-provider router won even over a healthy Docker-discovered backend; priority `1` fixed it.
-
-## 5. Wake path wiring: generate the static route, dispatch to the gateway (D2, D3, D5)
-
-- [x] ~~5.1 Add a `depends_on` block to a `deferStart` resource's compose entry~~ — **Superseded, 2026-09-26**: verified empirically that Compose `depends_on` cannot validly reference any of TDK's real cross-file dependencies here at all (see design.md D5's third finding — `docker compose config` rejects it outright, even across files sharing one `project_name`). D5 now relies entirely on the gateway's own explicit `X-Wake-Deps` handling (already built in task 4.3), not on anything compose-level.
-- [x] ~~5.2 Add `--provider.docker.honor-restart-policy=true`~~ — **Removed, 2026-09-26**: its only stated purpose was supporting `depends_on`'s `service_completed_successfully` condition, which 5.1's finding ruled out entirely; reverted from `traefik_standalone.star` rather than shipping unused config.
-- [x] 5.3 Wire the static route generator (task 4.2) into the real registration pipeline: for a `deferStart` backend resource, `register_compose_resources` (`apply_compose_resource_registration.star`) now calls `generate_static_wake_route` and writes it to `PlatformDockerConstants.TRAEFIK_DYNAMIC_DIR_REL + '/<resource>.yml'` via the existing `write_file` callback, right where its Traefik Docker labels are otherwise generated. Scoped to backends only for now (matching the proposal's motivating case) and with an empty dependency list (D5: TDK's real dependencies can't go through `depends_on`, and are either always-on infra that doesn't need waking, or a peer `deferStart` resource, left as a follow-up rather than guessed at — see the code comment at the call site). Verified: `resource_defers_start` and `generate_static_wake_route` unit/snapshot tests pass with this import wired in; full pipeline exercise (real `Docker.backend_compose`/file writes) folded into task 7.2's live run rather than duplicated with a synthetic project, consistent with how task 3.2 was verified.
-- [x] 5.4 Confirm the held request is answered only once the resource (and any dependencies named in `X-Wake-Deps`) are healthy, and fails with a clear timeout error past the configured duration instead of hanging. **Already verified** in task 4.3's live rehearsal (the gateway's timeout path and `evaluateReadiness` logic are exercised by `decide.test.ts` and were hit for real during debugging before the fixes landed — several requests genuinely timed out with a clear 504 rather than hanging).
-
-## 6. tdk up / tdk doctor reporting (D6)
-
-- [x] 6.1 Add a "deferred" resource classification to `tdk up`'s summary output, sourced from the resolved `sablier.enable && sablier.deferStart` per manifest (not from container state). **Done**: `cli/src/commands/up.ts`'s Backend API URLs list tags a deferred resource `(deferred — starts on first request)`. Verified by `npm run typecheck` (clean); no existing test harness covers `tdk up`'s interactive output at all (nothing to extend proportionately for one label — the full end-to-end pass in task 7.2 exercises it against the real landscape instead).
-- [x] 6.2 Make `tdk doctor` skip its usual "not running" / "unhealthy" flags for a resource classified as deferred and never yet triggered, per `doctor-runtime.ts`. **Done**: `parseTiltResourceFailures` now takes a `deferredNames` set and reports a deferred resource's `none`/`pending` status as its own `deferredCount`, separate from genuine `pendingCount` — its message no longer says "often blocked by the failures above" for these. `getDeferredResourceNames()` (via `discoverResources()`) supplies that set in `checkTiltResourceHealth`, best-effort (empty set, not a throw, if discovery fails). A genuinely failing resource is unaffected either way — `deferStart` never touches the `failures` branch. 2 new test cases pass in `doctor.test.ts` (29/29 total, no regressions); a resource that's been triggered but is still unhealthy would surface via Tilt's own `error` status, already covered by the existing failure-path tests.
-
-## 7. Documentation and integration
-
-- [x] 7.1 Document `deferStart` in the same place the `sablier` block itself is documented. **Done**: this repo has no separate docs file for `sablier` at all — its only documentation is `schema.star`'s field description and `resource-features.ts`'s feature entry, both already updated in group 2/task 2.2 (D5's `depends_on` mention removed from that description since D5 no longer uses it). No standalone docs page exists to additionally update.
-- [ ] 7.2 Re-vendor into `tdk-erp-system` (`tdk project --yes`, touch the Tiltfile, rebuild affected images), set `sablier: {enable: true, deferStart: true}` on `data-governance-api`'s `service.json`, and run a full `tdk up`. Verify that `data-governance-api` does not start during the initial bring-up, that `curl http://api.tdk-erp-system.localhost/api/data-governance/health` while the rest of the landscape is still starting returns a real (not `404`/connection-refused) health response within the resource's normal cold-start time — directly closing the gap reproduced live during design (see design.md Context) — and that `tdk doctor` does not flag it before that request and does not flag it as broken after. **Still open, in progress on the developer's own machine (2026-09-27):**
-  - Confirmed the free-tier key in `.env` grants nothing (`⚠️ No premium resources unlocked for this key`); the license-gated overlay was exercised by manually copying `tdk-cli-extensions/premium/networking/sablier_container_cycle.star` over the vendored stub, which is exactly what a real grant would do (`vendorTdkExtension()`'s own overlay step, `template-engine.ts`).
-  - Added the `sablier` block to `data-governance-api/service.json`, re-vendored, and confirmed the generated route (`traefik-dynamic/data-governance-api.yml`) and cold behavior (no container until first request) all work as designed.
-  - First real pass found and fixed two genuine bugs (not environment noise): (a) task 7.4's queue-bypass fix (`tilt trigger` alone queued behind Tilt's build-slot cap and 504'd — see D3); (b) after that fix, a second real bug — the app only serves its bare health path (`/health`), and the generated wake route forwarded the full public path (`/api/data-governance/health`) unstripped, unlike the real Docker-label `-project` router, so a successful wake still 404'd. Fixed by adding a matching `stripPrefix` middleware to the generated route (`traefik_static_routes.star`), reusing the same `cli_api_path()` the Docker-label router strips with. Both fixes are unit/Starlark-tested (33/33 passing) and re-vendored into the live project.
-  - **Re-test after both fixes is inconclusive, not failing**: a `docker rm -f` + cold curl got a `502` from Traefik itself (not the gateway's own 504), and the gateway's log showed only its initial "wake" decision line, never a "compose start ... started/failed" result — `docker compose up` inside the gateway appears to have stalled rather than erred. Root-caused to the machine, not the code: `tilt get uiresource` showed **104 of 250 resources still `pending`**, mid a mass rebuild (Tilt's build-slot cap processing 3 at a time) triggered by this task's own repeated `tdk project --yes` + forced-Tiltfile-re-eval cycles across this session — sustained load average ~26-27, `docker ps`/`traefik ping` themselves taking 10-30s, and Traefik logged a stale `data-governance-api@docker` service IP getting "no route to host" consistent with a container that started to come up and was torn down mid-flight under this contention. **Decision (2026-09-27, developer's own call, not further probed by any session)**: stop touching the live landscape rather than keep polling an already-overloaded daemon (load average climbed to ~38 after this note was first written, queue hadn't drained) or force a Docker Desktop restart that would kill the ~110 containers of a 14+-hour-running landscape. The code changes (task 7.4's queue-bypass fix and this task's strip-prefix fix) ship as-is on the strength of their unit/Starlark tests (33/33 passing) plus the one clean live pass that *did* complete end-to-end before the path-stripping bug was found (container created from cold via direct compose start, no Tilt-queue wait, "compose start data-governance-api: started" logged, and a genuine 502→200 progression as each bug was fixed in turn) — not on an unattainable final green run under a saturated host. This task stays open (checkbox unchecked) rather than being marked done on inference: the one remaining step is a single clean re-run of `curl http://api.tdk-erp-system.localhost/api/data-governance/health` against a quiescent `tdk-erp-system` landscape, entirely at the developer's own convenience, with no further re-vendor/re-eval cycles needed first (the fixes are already vendored in).
-  - **Live re-test passed, 2026-09-27 18:55** (landscape quiet: Tilt no longer running, load ~17, no re-vendor/re-eval needed): warm `curl http://api.tdk-erp-system.localhost/api/data-governance/health` → `200` with the real health body in 0.6s (the same request 404'd before task 7.5's strip-prefix fix). Then `docker rm -f` the container, confirmed absent, same `curl` → **`200` `{"status":"healthy",...}` in 19.2s** from fully cold. Gateway log: `wake data-governance-api: state=absent compose=true trigger=[]` → `compose start data-governance-api: started` — task 7.4's direct-start path, no Tilt involvement at all (Tilt was not even running). This closes the proposal's motivating gap on the real landscape. Side observation: Traefik's own Docker-label routers for this resource are `disabled` because the Sablier Traefik plugin fails its integrity check on download (`plugin integrity check failed`, plugins disabled), so every request currently goes through the wake route — a separate, pre-existing plugin-download problem, not part of this change.
-  - **Still unverified live (why the box stays unchecked):** the two parts of 7.2 that need Tilt itself running — (a) task 3.3, that a fresh `tdk up` leaves `data-governance-api` with no container until its first request, and (b) that `tdk doctor` reports it as deferred rather than stalled. Both are covered by unit tests (3.1/3.2 predicate tests, 6.2's doctor tests) but not yet observed on this landscape. Next step: one `tdk up` in `tdk-erp-system`, then `docker ps -a --filter name=data-governance-api` (expect nothing) and `tdk doctor`.
-  - **`tdk up` run, 2026-09-27 19:08 (global `tdk` 1.3.51, premium overlay in place, container removed first):**
-    - ✅ `tdk up`'s summary printed `data-governance-api: .../api/data-governance/health (deferred — starts on first request)` (task 6.1, live).
-    - ✅ After the Tiltfile evaluated, Tilt left `data-governance-api` at `updateStatus: none` / `runtimeStatus: none` and created no container (task 3.3's container half, live).
-    - ❌ **Image not built.** Contrary to the design comment in `_register_single_resource` and the spec's "Deferred Start Opt-In" requirement, `auto_init=False` skips the resource's image build as well as its container: this Tilt session recorded zero builds for `data-governance-api`, and its newest image predates the session. The image only existed because earlier sessions built it. On a fresh project the first wake finds no image, `ensureImage()` fails, and the gateway falls back to `tilt trigger` — the queueing path task 7.4 was meant to avoid.
-    - ❌ **Cold wake during a full bring-up timed out for the caller.** Hit the URL at 19:10:42 with 134 resources pending: the gateway chose the direct compose path (`state=absent compose=true`), but `docker image inspect` took ~2 min and `docker compose up` ~3 min more because the Docker daemon itself was saturated by the bring-up (`tdk doctor` also aborted: `docker ps` hung >10s). The container started at 19:15:36 (~5 min), after Bun's 255s idle timeout had already dropped the client connection (`HTTP 000`). A follow-up request returned `200` in 16s. So bypassing Tilt's build queue works, but under a full bring-up the Docker daemon is the next bottleneck, and the gateway gives the caller no response in that case.
-    - ⏸ `tdk doctor`'s deferred reporting (6.2) not observed yet: doctor exits at its Docker-responsiveness check while the daemon is this loaded.
-  - **Open decisions, resolved by the developer 2026-09-27:** (1) build the image during `tdk up` → task 7.7; (2) answer slow wakes with an early `503` + `Retry-After` → task 7.8. Both implemented and tested; neither re-vendored into `tdk-erp-system` yet. **What remains for this task:** re-vendor, then one `tdk up` to confirm the `data-governance-api-image` resource builds and the container stays absent, a cold request during bring-up to confirm a `503` + `Retry-After` followed by a successful retry, and `tdk doctor` once the Docker daemon is responsive enough for its 10s check.
-  - **2026-09-27 disposable probe (torn down after, nothing kept):** to verify task 7.3's fix end-to-end rather than only at the Starlark-unit level, stood up an isolated Tilt + Docker Compose project (two `traefik/whoami` services, `dep-service` and `primary-service`, both `dc_resource(auto_init=False)`) plus a standalone Traefik with the file provider enabled. Generated `primary-service`'s static route with the **real, unmodified** `generate_static_wake_route()` from `traefik_static_routes.star`, passing `dependencies=[("dep-service", "wakeprobe")]` the same shape `resolve_defer_start_dependencies` now produces — confirmed the emitted YAML carries `X-Wake-Deps: "dep-service=wakeprobe-dep-service-1"`. Ran the real `wake-gateway/server.ts` (as a local Bun process against this container's own Tilt daemon and Docker socket, since building the packaged Docker image failed here on an unrelated Alpine/`apk` proxy TLS issue — the packaged image itself is unaffected, this only affected building it ad hoc in this sandbox). A single HTTP request against `primary-service`'s route, while both containers were confirmed absent beforehand, resulted in **both** `wakeprobe-primary-service-1` and `wakeprobe-dep-service-1` being created and started (verified via `docker ps` and `tilt logs` showing both `tilt trigger` calls succeed) — this is the exact behavior task 7.3 added and that D5's requirement describes, now observed working end-to-end, not just unit-tested. The final proxy-through step returned a connection error, but only because the gateway ran as a host process outside the Compose network and so couldn't resolve the container's Compose-DNS name (`primary-service`) — confirmed by curling the container's bridge IP directly and getting a real `200`; that proxy-through mechanic itself was already verified live in task 4.3's own probe when the gateway ran inside the correct Docker network, and is unrelated to 7.3's change. One real, unrelated hiccup along the way: `primary-service`'s first `tilt trigger` failed with a Docker Hub `429 Too Many Requests` on the image pull (transient registry throttling, not a bug); a second trigger with the image already cached succeeded normally.
-- [x] 7.3 (Found 2026-09-26 re-reading the shipped code) Wire real dependency data into the `generate_static_wake_route(...)` call at `apply_compose_resource_registration.star:442` — it always passed no `dependencies=` argument, so every generated route shipped `X-Wake-Deps: ""` despite the gateway side and the generator's `dependencies` param both being implemented and unit-tested in isolation. **Done, 2026-09-26**: added `resolve_manifest_dependency_names(manifest, all_services_map)` (reuses the existing `_resolve_dependency_to_resource` that `_build_resource_deps` already trusts for Tilt's own `resource_deps` ordering — an ambiguous name behaves identically here as it already does there) and `resolve_defer_start_dependencies(manifest, resource_manifests, all_services_map)` (filters those resolved names to the ones whose own manifest is itself `resource_defers_start`), both in `apply_compose_resource_registration.star`, no leading underscore so they're directly `load()`-able for tests per task 3.1's precedent. The call site now passes `dependencies=resolve_defer_start_dependencies(manifest, resource_manifests, all_services_map)`. 6 new cases in `test_sablier_defer_start.py` cover: exact-name resolution, an unresolvable name falling back to exclusion (not a guess), a dependency that resolves but isn't itself deferStart, and the free-tier license gate keeping the result empty even for a `dependsOn` target whose manifest asks for `deferStart` (mirrors task 3.1's own license-gate tests, since `resource_defers_start` is reused unchanged) — full 166/166 passing (166 = prior 160 + these 6; the pre-existing 29 unrelated failures in `tests/tilt-engine/` — `test_agents_md_*`, `test_daemon_*`, `test_snapshot_scanning`, etc. — are identical before and after this change, confirmed by diffing the failure list against a `git stash` baseline). The "licensed and actually wakes a peer deferStart resource" end-to-end case still can't be exercised from this repo's free-tier stub, same limitation task 3.1 already documented — folded into task 7.2's live run rather than duplicated here.
-
-- [x] 7.5 (Found live during task 7.2's real `tdk-erp-system` run, 2026-09-27, immediately after 7.4's fix) A woken resource still 404'd: the app only serves its bare health path (e.g. `/health`), but the generated wake route forwarded the full public path (`/api/data-governance/health`) unstripped — unlike the real Docker-label `-project` router, which strips that prefix via its own `stripprefix` middleware (`traefik.star`'s `get_backend_traefik_labels`). **Done**: `generate_static_wake_route` (`traefik_static_routes.star`) now emits a matching `stripPrefix` middleware ahead of the headers middleware, reusing the same `cli_api_path()` the Docker-label router already strips with, so the two paths agree by construction rather than by convention. New `test_static_route_strips_the_same_api_path_prefix_the_docker_router_does` case (asserts the middleware exists, strips the right prefix, and runs before the headers middleware in the router's list) — 34/34 Starlark tests passing. Re-vendored into `tdk-erp-system` and confirmed via `docker exec ... wget /health` (200) vs `wget /api/data-governance/health` (404) against the real container that the app itself only serves the stripped path, proving the fix addresses a real gap rather than a theoretical one.
-
-- [x] 7.6 Benchmark task 7.4's queue-bypass fix with real, reproducible numbers rather than relying solely on the one interrupted live pass. **Done, 2026-09-27**: a disposable, isolated benchmark (own Tilt instance on a private port, own Compose project, torn down completely after — no interaction with any real project) exercising the actual shipped `generate_static_wake_route()`/`decide.ts`/`server.ts` code against a genuine build-slot queue (`max_parallel_updates=2`, six slow-building filler resources). Full setup, results table, and interpretation recorded in `design.md`'s new "Benchmark: D3's queue-bypass fix, measured" section. Headline results: the new direct-start path (`target-fast`) answered in 7.4-12.6s regardless of whether the build queue was saturated; the old `tilt trigger`-only fallback (`target-slow`) cost 18.1-22.8s even at its best (idle) case, confirmed via Tilt's own build history to be paying its build-reconciliation step unconditionally — the same step that queues behind other builds and caused the original live `504`.
-
-- [x] 7.7 (Found live, task 7.2's `tdk up` run, 2026-09-27) Build a deferred resource's image during `tdk up`: `auto_init=False` also skipped its `docker_build`, contrary to D1's original assumption. **Done** (`3f25fe6`): `_register_deferred_image_prebuild` adds a `<name>-image` `local_resource` per `deferStart` resource that builds the same image under the compose-declared tag, using a Dockerfile copy with an allowlist `.dockerignore` from the new `TypescriptBuilders.prebuild_dockerignore` (mirrors `docker_build`'s `only=`/`ignore=`). New `test_prebuild_dockerignore_mirrors_docker_build_only_and_ignore` case; 35/35 related Starlark tests pass. Verified by hand on `data-governance-api` with the exact command the resource runs (throwaway tag): 14 kB context, all layers cached, filesystem layers identical to Tilt's image.
-
-- [x] 7.8 (Found live, task 7.2's `tdk up` run, 2026-09-27) Never drop a waking request silently. **Done** (`3f25fe6`): `server.ts` holds for `earlyResponseMs()` (60s default, `X-Wake-Respond-Within-Ms` override capped at 240s under Bun's 255s idle limit), then answers `503` + `Retry-After: 10` while the start continues; an in-flight map keeps one wake per resource so retries join it. Spec updated ("Startup outlasts the hold window" scenario). 18/18 `bun test` cases pass (4 new for the timing rules); `server.ts`/`decide.ts` type-check under `strict` with Bun types. Not yet exercised live: the in-flight join and the 503 path need a slow start to observe (task 7.2's remaining step).
-
-- [x] 7.4 (Found live during task 7.2's real `tdk-erp-system` run, 2026-09-27) `tilt trigger`-only wake failed under real load: with ~100+ resources mid-rebuild after a re-vendor (Tilt caps concurrent builds at a handful of slots), a triggered `deferStart` resource sat queued behind them and the request timed out with a `504` — the exact "wait behind a huge landscape" problem this feature exists to remove, just relocated to Tilt's build queue. **Done**: the gateway now prefers creating/starting the resource directly with `docker compose up -d --no-build <resource>` (the same command Tilt's own `<resource>-run-only` local_resource runs) whenever the generated route supplies the resource's compose invocation, falling back to `tilt trigger` only when no image has ever been built for it yet (`ensureImage()` first tries retagging Tilt's own `<repo>:tilt-<hash>` build as `<repo>:dev` in case the plain tag was never created). Changes: `decide.ts`'s `decideWakeAction` gained `useComposeStart`/`hasComposeInvocation` and `wakeTimeoutMs()` (180s for a direct start, 240s when a build might be needed, under Bun's 255s idle cap) with new `decide.test.ts` cases; `server.ts` gained `composeStart()`/`ensureImage()` and reads `X-Wake-Compose-Project`/`X-Wake-Compose-Files`/`X-Wake-Env-File`/`X-Wake-Image`; `traefik_static_routes.star`'s `generate_static_wake_route` gained matching optional params/headers (new `test_static_route_carries_compose_invocation_for_direct_start` case) plus a `normalize_abs_path()` helper (Tilt's `os.path.abspath` doesn't collapse `..`, and the generated Tiltfile's project root is exactly `config.main_dir + "/../.."` — confirmed with a throwaway probe, new `test_normalize_abs_path_collapses_dot_segments` case); `apply_compose_resource_registration.star` gained `_wake_compose_invocation()` wiring the resource's actual compose files/env/image into the call site; `traefik_standalone.star` mounts the project root read-only into the gateway container at the same normalized absolute path so those compose files resolve identically there (new `test_wake_gateway_mounts_project_root_at_its_own_absolute_path` case). Dockerfile gained `docker-cli-compose`. 33/33 Starlark tests and the full `bun test` suite (25 assertions) pass. Live re-verification against `tdk-erp-system` (re-vendored, route regenerated with the new headers, gateway/Traefik rebuild in progress under the same real build-queue contention that motivated this) folded into 7.2's final result below rather than duplicated here.

package/openspec/config.yaml

@@ -1 +0,0 @@
-schema: spec-driven

package/openspec/specs/manifest-field-migration/spec.md

@@ -1,24 +0,0 @@
-# manifest-field-migration Specification
-
-## Purpose
-TBD - created by archiving change rename-domain-to-stack-service-to-resource. Update Purpose after archive.
-## Requirements
-### Requirement: Manifest field migration from domain to stack
-All manifest field access patterns SHALL remove fallback support for the deprecated `domain` field.
-
-#### Scenario: No domain field fallback
-- **WHEN** code retrieves the stack field from a manifest
-- **THEN** it SHALL NOT use fallback patterns like `manifest.get('stack') or manifest.get('domain')`
-
-#### Scenario: Stack field with default only
-- **WHEN** a default value is needed for the stack field
-- **THEN** code SHALL use `manifest.get('stack', default_value)` and NOT check for domain
-
-#### Scenario: Domain field references removed
-- **WHEN** searching the codebase for domain field access
-- **THEN** no `manifest.get('domain')` patterns SHALL exist except in legacy parser code
-
-#### Scenario: Filtering uses stack field only
-- **WHEN** filtering manifests by logical group
-- **THEN** code SHALL filter by `stack` field only and NOT check `domain` as fallback
-

package/openspec/specs/resource-terminology-standard/spec.md

@@ -1,24 +0,0 @@
-# resource-terminology-standard Specification
-
-## Purpose
-TBD - created by archiving change rename-domain-to-stack-service-to-resource. Update Purpose after archive.
-## Requirements
-### Requirement: Resource terminology standardization
-All references to deployable units SHALL use the term "resource" instead of "service".
-
-#### Scenario: Function parameters use resource terminology
-- **WHEN** a function accepts a deployable unit as a parameter
-- **THEN** the parameter name SHALL be `resource` or `resource_dict` and NOT `service` or `svc`
-
-#### Scenario: Docstrings use resource terminology
-- **WHEN** a function docstring describes a deployable unit
-- **THEN** it SHALL use the term "resource" and NOT "service"
-
-#### Scenario: Variable names use resource terminology
-- **WHEN** a variable holds a deployable unit
-- **THEN** the variable name SHALL be `resource` and NOT `svc` or `service`
-
-#### Scenario: Comments use resource terminology
-- **WHEN** code comments describe deployable units
-- **THEN** they SHALL use the term "resource" and NOT "service"
-

package/openspec/specs/self-contained-generated-projects/spec.md

@@ -1,67 +0,0 @@
-# Self-Contained Generated Projects
-
-## ADDED Requirements
-
-### Requirement: Generated Services Compile On First Run
-
-Generated backend services must always emit valid Bun source code.
-
-#### Scenario: Backend template with banner logs
-
-- **WHEN** a user runs `tdk resource api --type backend --stack pre-alpha --path services/pre-alpha/api`
-- **THEN** the generated `src/index.ts` contains `console.log('\n🚀 api running ...')` with an escaped `\n`
-- **AND** `bun run src/index.ts` starts the server without a syntax error
-
-#### Scenario: Health endpoint serves
-
-- **WHEN** the generated service is running
-- **THEN** `GET /health` responds `{"status":"ok","service":"<name>"}`
-
-### Requirement: Extension Vendored Into Generated Projects
-
-Every generated project must contain the TDK Tilt extension so `tdk up` works offline.
-
-#### Scenario: Project generation
-
-- **WHEN** a user runs `tdk project --yes`
-- **THEN** `.tdk/.tdk-out/tdk-cli-ext/` is created containing `Tiltfile`, `engine/`, `discovery/`, `specs/`, and `ext/`
-- **AND** the generation log reports `Vendored TDK extension -> .tdk/.tdk-out/tdk-cli-ext/`
-
-#### Scenario: Extension source auto-detection
-
-- **WHEN** generating a project
-- **THEN** the extension source is resolved in order: `$TDK_EXTENSION_SOURCE`, an executable-adjacent `tdk-cli` checkout, then a `../tdk-cli` sibling of the project root
-
-### Requirement: Tiltfile Loads Extension Locally
-
-The generated Tiltfile must resolve the extension without any GitHub dependency.
-
-#### Scenario: Vendored copy present
-
-- **WHEN** `.tdk/.tdk-out/tdk-cli-ext/` exists next to the Tiltfile
-- **THEN** the Tiltfile registers `file://<vendored path>` as the extension repo
-- **AND** `load('ext://tdk-cli', ...)` succeeds without cloning
-
-#### Scenario: Explicit extension path override
-
-- **WHEN** the vendored copy is absent but `$TDK_EXTENSION_PATH` points at a valid tdk-cli checkout
-- **THEN** the Tiltfile uses that path
-
-#### Scenario: No extension available
-
-- **WHEN** neither the vendored copy nor `$TDK_EXTENSION_PATH` exists
-- **THEN** loading fails fast with a single actionable error listing the three recovery options, with no retry loop
-
-### Requirement: No Machine-Specific Paths In Generated Output
-
-Generated Tiltfiles must never contain hardcoded author or machine paths.
-
-#### Scenario: Fresh generation on any machine
-
-- **WHEN** any user generates a project
-- **THEN** the generated `Tiltfile` has no absolute host-specific paths and no private GitHub repo URL fallback
-
-#### Scenario: Local probe is truthful
-
-- **WHEN** the Tiltfile probes for the vendored directory
-- **THEN** the probe echoes its outcome (`test -d <path> && echo yes || echo no`) so detection reflects the filesystem

package/openspec/specs/stack-terminology-standard/spec.md

@@ -1,24 +0,0 @@
-# stack-terminology-standard Specification
-
-## Purpose
-TBD - created by archiving change rename-domain-to-stack-service-to-resource. Update Purpose after archive.
-## Requirements
-### Requirement: Stack terminology standardization
-All references to logical grouping of resources SHALL use the term "stack" instead of "domain".
-
-#### Scenario: Manifest field access uses stack
-- **WHEN** code accesses the grouping field from a manifest
-- **THEN** it SHALL use `manifest.get('stack')` and NOT `manifest.get('domain')`
-
-#### Scenario: Cache keys use stack terminology
-- **WHEN** the discovery cache stores configuration for logical groups
-- **THEN** the cache key SHALL be named `stack_configs` and NOT `domain_configs`
-
-#### Scenario: Autogenerated files use stack naming
-- **WHEN** autogenerated index files are created for logical groups
-- **THEN** the filenames SHALL contain `stacks` and NOT `domains`
-
-#### Scenario: Function names use stack terminology
-- **WHEN** a function generates an index of logical groups
-- **THEN** the function name SHALL include `stacks` and NOT `domains`
-

package/platform/services/platform/proxy/service.yaml

@@ -1,14 +0,0 @@
-appName: proxy
-appType: infra
-stack: platform
-port: 80
-description: Traefik reverse proxy with dynamic routing
-features:
-  - traefik
-healthCheck: False
-dependsOn:
-  - database-management
-runtime: docker
-traefik:
-  host: traefik.tdk-project.localhost
-  pathPrefix: /dashboard

package/scripts/audit-codebase.sh

@@ -1,213 +0,0 @@
-#!/usr/bin/env bash
-#
-# TDK Codebase Audit Script
-# Scans for TODO, FIXME, BUG, HACK markers across all source files
-#
-
-set -e
-
-# Colors for output
-RED='\033[0;31m'
-YELLOW='\033[1;33m'
-BLUE='\033[0;34m'
-GREEN='\033[0;32m'
-GRAY='\033[0;90m'
-NC='\033[0m' # No Color
-
-# Directories to scan
-CLI_DIR="cli/src"
-DISCOVERY_DIR="discovery"
-ENGINE_DIR="engine"
-
-# File extensions to scan
-TS_EXTENSIONS="*.ts *.tsx"
-PY_EXTENSIONS="*.py"
-STAR_EXTENSIONS="*.star"
-GO_EXTENSIONS="*.go"
-
-# Markers to search for
-MARKERS="TODO|FIXME|XXX|BUG|HACK"
-
-echo -e "${BLUE}🔍 TDK Codebase Audit${NC}"
-echo -e "${GRAY}Scanning for: ${MARKERS}${NC}"
-echo ""
-
-# Counters
-cli_count=0
-discovery_count=0
-engine_count=0
-total_count=0
-
-# Temporary files for categorization
-CLI_FINDINGS=$(mktemp)
-DISCOVERY_FINDINGS=$(mktemp)
-ENGINE_FINDINGS=$(mktemp)
-
-# Function to scan a directory
-scan_directory() {
-    local dir="$1"
-    local name="$2"
-    local extensions="$3"
-    local output_file="$4"
-    local count=0
-
-    echo -e "${BLUE}📁 Scanning ${name}...${NC}"
-
-    if [ ! -d "$dir" ]; then
-        echo -e "${YELLOW}   ⚠️  Directory not found: ${dir}${NC}"
-        return 0
-    fi
-
-    for ext in $extensions; do
-        while IFS= read -r file; do
-            if [ -n "$file" ]; then
-                local findings=$(grep -n -E "${MARKERS}" "$file" 2>/dev/null || true)
-                if [ -n "$findings" ]; then
-                    echo "$file" >> "$output_file"
-                    echo "$findings" >> "$output_file"
-                    echo "" >> "$output_file"
-                    local file_count=$(echo "$findings" | wc -l)
-                    count=$((count + file_count))
-                fi
-            fi
-        done < <(find "$dir" -name "$ext" -type f 2>/dev/null)
-    done
-
-    echo -e "${GREEN}   ✅ Found ${count} marker(s)${NC}"
-    return $count
-}
-
-# Scan CLI (TypeScript)
-scan_directory "$CLI_DIR" "CLI (TypeScript)" "$TS_EXTENSIONS" "$CLI_FINDINGS"
-cli_count=$?
-
-# Scan Discovery (Python and Starlark)
-scan_directory "$DISCOVERY_DIR" "Discovery (Python/Starlark)" "$PY_EXTENSIONS $STAR_EXTENSIONS" "$DISCOVERY_FINDINGS"
-discovery_count=$?
-
-# Scan Engine (Starlark)
-scan_directory "$ENGINE_DIR" "Engine (Starlark)" "$STAR_EXTENSIONS $GO_EXTENSIONS" "$ENGINE_FINDINGS"
-engine_count=$?
-
-# Calculate total
-total_count=$((cli_count + discovery_count + engine_count))
-
-echo ""
-echo -e "${BLUE}═══════════════════════════════════════════════════════════════${NC}"
-echo -e "${BLUE}📊 AUDIT REPORT${NC}"
-echo -e "${BLUE}═══════════════════════════════════════════════════════════════${NC}"
-echo ""
-
-# Category: CLI (User-facing)
-echo -e "${YELLOW}🔴 CLI (User-Facing) - ${cli_count} finding(s)${NC}"
-echo -e "${GRAY}   These affect user commands and should be prioritized${NC}"
-if [ -s "$CLI_FINDINGS" ]; then
-    cat "$CLI_FINDINGS"
-fi
-echo ""
-
-# Category: Core (Discovery/Engine)
-echo -e "${YELLOW}🟡 Core (Discovery/Engine) - $((discovery_count + engine_count)) finding(s)${NC}"
-echo -e "${GRAY}   Infrastructure code - affects service discovery and orchestration${NC}"
-
-if [ -s "$DISCOVERY_FINDINGS" ]; then
-    echo -e "${BLUE}   Discovery:${NC}"
-    cat "$DISCOVERY_FINDINGS"
-fi
-
-if [ -s "$ENGINE_FINDINGS" ]; then
-    echo -e "${BLUE}   Engine:${NC}"
-    cat "$ENGINE_FINDINGS"
-fi
-echo ""
-
-# Summary
-echo -e "${BLUE}═══════════════════════════════════════════════════════════════${NC}"
-echo -e "${BLUE}📈 SUMMARY${NC}"
-echo -e "${BLUE}═══════════════════════════════════════════════════════════════${NC}"
-echo -e "Total markers found: ${total_count}"
-echo ""
-echo -e "By category:"
-echo -e "  - CLI (User-facing):     ${cli_count}"
-echo -e "  - Discovery:              ${discovery_count}"
-echo -e "  - Engine:                ${engine_count}"
-echo ""
-
-if [ $total_count -eq 0 ]; then
-    echo -e "${GREEN}✨ No technical debt markers found!${NC}"
-else
-    echo -e "${YELLOW}⚠️  Action required: Review and address findings above${NC}"
-fi
-
-# Save report to file
-REPORT_FILE="codebase-audit-report-$(date +%Y%m%d-%H%M%S).md"
-cat > "$REPORT_FILE" << EOF
-# TDK Codebase Audit Report
-
-Generated: $(date)
-
-## Summary
-
-- **Total markers found:** ${total_count}
-- **CLI (User-facing):** ${cli_count}
-- **Discovery:** ${discovery_count}
-- **Engine:** ${engine_count}
-
-## Findings
-
-### CLI (User-Facing) - Priority: HIGH
-
-\`\`\`
-EOF
-
-if [ -s "$CLI_FINDINGS" ]; then
-    cat "$CLI_FINDINGS" >> "$REPORT_FILE"
-else
-    echo "No findings" >> "$REPORT_FILE"
-fi
-
-cat >> "$REPORT_FILE" << EOF
-\`\`\`
-
-### Discovery - Priority: MEDIUM
-
-\`\`\`
-EOF
-
-if [ -s "$DISCOVERY_FINDINGS" ]; then
-    cat "$DISCOVERY_FINDINGS" >> "$REPORT_FILE"
-else
-    echo "No findings" >> "$REPORT_FILE"
-fi
-
-cat >> "$REPORT_FILE" << EOF
-\`\`\`
-
-### Engine - Priority: MEDIUM
-
-\`\`\`
-EOF
-
-if [ -s "$ENGINE_FINDINGS" ]; then
-    cat "$ENGINE_FINDINGS" >> "$REPORT_FILE"
-else
-    echo "No findings" >> "$REPORT_FILE"
-fi
-
-cat >> "$REPORT_FILE" << EOF
-\`\`\`
-
-## Next Steps
-
-1. Review HIGH priority (CLI) findings first
-2. Implement or remove TODOs as appropriate
-3. Add tests for any new functionality
-4. Re-run audit to verify cleanup
-EOF
-
-echo -e "${BLUE}💾 Full report saved to: ${REPORT_FILE}${NC}"
-
-# Cleanup
-rm -f "$CLI_FINDINGS" "$DISCOVERY_FINDINGS" "$ENGINE_FINDINGS"
-
-exit 0