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

package/CHANGELOG.md

@@ -4,6 +4,15 @@ Notable changes to the `tdk` CLI. Versions match [npm](https://www.npmjs.com/pac
 
 ## Unreleased
 
+- Dropped the `ora` dependency (only `tdk upgrade` used it) in favor of a small built-in spinner: 50 installed packages instead of 61, and no more duplicate versions of cli-cursor, restore-cursor, onetime and signal-exit.
+- `tdk doctor` outside a project checks only Docker, Compose and Tilt, and reports "This machine is ready for TDK". Before, running it right after installing (as the installer suggests) failed with "Master configs missing … Environment not ready".
+
+## 1.3.54 (2026-09-27)
+
+- The npm package ships only what the CLI needs at runtime: 294 files and 458 kB, down from 678 files and 888 kB. Repo tooling, tests, source maps, CI config and the openspec docs are no longer included.
+
+## 1.3.53 (2026-09-27)
+
 - The "requires a license key" errors link to the working request form (`tdk-landscape.github.io/tdk-website/#waitlist`); the old link pointed at a page without it.
 - New issue template for Premium license requests.
 

package/README.md

@@ -172,7 +172,7 @@ make pre-commit-run # run pre-commit hooks on all files
 tdk doctor
 ```
 
-Verifies Docker, Bun, Tilt, required ports, and master config files are all in place before you run `tdk up`.
+Checks Docker, Compose and Tilt. Inside a project it also checks the generated configs, `.env`, service scripts and that the ingress ports are free, before you run `tdk up`.
 
 ## Community
 

package/cli/dist/commands/doctor.js

@@ -681,11 +681,13 @@ export const doctorCommand = new Command("doctor")
         console.log(`${chalk.red("✗")} --ping-timeout must be a positive number of milliseconds`);
         process.exit(1);
     }
-    const checks = [
+    const machineChecks = [
         checkDockerRuntime,
         checkTilt,
         checkDockerCompose,
         checkDockerVersions,
+    ];
+    const projectChecks = [
         checkMasterConfigs,
         checkGeneratedProjectRuntimeAssets,
         checkStarlarkLoadExports,
@@ -704,8 +706,13 @@ export const doctorCommand = new Command("doctor")
     ];
     // Runs last: needs routable services (and working Traefik) to mean anything.
     if (options.ping) {
-        checks.push(() => checkServiceHealth(pingTimeout));
+        projectChecks.push(() => checkServiceHealth(pingTimeout));
     }
+    // Right after installing, people run `tdk doctor` before they have a
+    // project. Only the machine checks mean anything there; the project checks
+    // would all fail with "run tdk project".
+    const inProject = Boolean(findProjectRoot());
+    const checks = inProject ? [...machineChecks, ...projectChecks] : machineChecks;
     let allPassed = true;
     for (const checkFn of checks) {
         const result = await checkFn();
@@ -728,7 +735,18 @@ export const doctorCommand = new Command("doctor")
         }
     }
     console.log("");
-    if (allPassed) {
+    if (allPassed && !inProject) {
+        console.log(`${chalk.gray("○")} ${chalk.gray("Not in a TDK project, so project checks were skipped")}`);
+        console.log("");
+        console.log(`${chalk.green(chalk.bold("✓"))} This machine is ready for TDK`);
+        console.log("");
+        console.log("Next steps:");
+        console.log("  1. mkdir my-app && cd my-app");
+        console.log("  2. tdk project --yes");
+        console.log("  3. tdk resource api --type backend --stack my-app");
+        console.log("  4. tdk up my-app");
+    }
+    else if (allPassed) {
         console.log(`${chalk.green(chalk.bold("✓"))} Environment ready for TDK`);
         console.log("");
         console.log("Next steps:");

package/cli/dist/commands/upgrade.js

@@ -5,11 +5,11 @@ import { dirname, join, resolve } from "node:path";
 import { fileURLToPath } from "node:url";
 import chalk from "chalk";
 import { Command } from "commander";
-import ora from "ora";
 import { getErrorMessage, logVerbose, showErrorAndExit } from "../utils/errors.js";
 import { showCancelled } from "../utils/formatting.js";
 import { getPackageVersion } from "../utils/paths.js";
 import { promptConfirm } from "../utils/prompt.js";
+import { startSpinner } from "../utils/spinner.js";
 function isStandaloneBinary(tdkPath) {
     try {
         const fileInfo = execSync(`file -b ${JSON.stringify(tdkPath)}`, { encoding: "utf-8" });
@@ -138,7 +138,7 @@ export async function upgradeViaBinary(tdkPath, release) {
         console.log(chalk.cyan(`   chmod +x ${tdkPath}`));
         return false;
     }
-    const spinner = ora(`Downloading ${release.assetName} (${release.tag})...`).start();
+    const spinner = startSpinner(`Downloading ${release.assetName} (${release.tag})...`);
     // Download to /tmp first (both the binary and the engine bundle below) so a
     // failed network step can't leave a half-written binary at tdkPath.
     const tmpPath = `/tmp/tdk-upgrade-${release.assetName}`;
@@ -204,7 +204,7 @@ function getCurrentVersion() {
     }
 }
 async function getLatestVersion() {
-    const spinner = ora("Checking for latest version...").start();
+    const spinner = startSpinner("Checking for latest version...");
     try {
         const result = execSync("npm view @tdk-landscape/tdk-cli-core version", {
             encoding: "utf-8",
@@ -224,7 +224,7 @@ async function getLatestVersion() {
     }
 }
 async function upgradeViaNpm() {
-    const spinner = ora("Upgrading via npm...").start();
+    const spinner = startSpinner("Upgrading via npm...");
     try {
         execSync("npm install -g @tdk-landscape/tdk-cli-core@latest", {
             stdio: "inherit",
@@ -252,7 +252,7 @@ async function upgradeViaNpm() {
     }
 }
 async function upgradeViaBun() {
-    const spinner = ora("Upgrading via bun...").start();
+    const spinner = startSpinner("Upgrading via bun...");
     try {
         execSync("bun install -g @tdk-landscape/tdk-cli-core@latest", {
             stdio: "inherit",
@@ -280,7 +280,7 @@ async function upgradeViaBun() {
     }
 }
 async function upgradeViaGit(path) {
-    const spinner = ora("Pulling latest changes from git...").start();
+    const spinner = startSpinner("Pulling latest changes from git...");
     try {
         execSync("git rev-parse --git-dir", {
             cwd: path,
@@ -492,7 +492,7 @@ export const upgradeCommand = new Command("upgrade")
         process.exit(1);
     }
     console.log();
-    const verifySpinner = ora("Verifying upgrade...").start();
+    const verifySpinner = startSpinner("Verifying upgrade...");
     try {
         const newVersion = execSync("tdk version", { encoding: "utf-8" }).trim();
         verifySpinner.succeed(`Verified: now running ${chalk.green(newVersion)}`);

package/cli/dist/generator/extension-fetch.js

@@ -94,15 +94,25 @@ function isCacheFresh(path) {
         return false;
     return Date.now() - statSync(path).mtimeMs < CACHE_TTL_MS;
 }
+// Sends the key as `Authorization: Bearer`, never in the URL, where request
+// logs and proxies record it. A worker deployed before it read the header
+// answers 401 "missing key" (a current one only returns 401 when it gets no
+// key at all), so retry that once with the old `?key=` - premium keeps
+// working until the worker is updated. Drop the retry once it is.
+async function fetchPremium(key, resource, projectId) {
+    const url = `${getEndpoint()}?resource=${encodeURIComponent(resource)}` +
+        `&projectId=${encodeURIComponent(projectId)}`;
+    const res = await fetch(url, { headers: { Authorization: `Bearer ${key}` } });
+    if (res.status !== 401)
+        return res;
+    await res.arrayBuffer().catch(() => undefined);
+    return fetch(`${url}&key=${encodeURIComponent(key)}`);
+}
 async function fetchPremiumBundle(key, projectId) {
-    const endpoint = getEndpoint();
     for (const resource of KNOWN_RESOURCES) {
-        const url = `${endpoint}?key=${encodeURIComponent(key)}` +
-            `&resource=${encodeURIComponent(resource)}` +
-            `&projectId=${encodeURIComponent(projectId)}`;
         let res;
         try {
-            res = await fetch(url);
+            res = await fetchPremium(key, resource, projectId);
         }
         catch (err) {
             console.warn(`⚠️  Premium fetch failed (network error): ${err.message}`);
@@ -208,12 +218,9 @@ async function hasLiveResourceLicense(projectRoot, resource) {
         }
     }
     const projectId = getOrCreateProjectId(projectRoot);
-    const endpoint = getEndpoint();
-    const url = `${endpoint}?key=${encodeURIComponent(key)}` +
-        `&resource=${encodeURIComponent(resource)}&projectId=${encodeURIComponent(projectId)}`;
     let granted = false;
     try {
-        const res = await fetch(url);
+        const res = await fetchPremium(key, resource, projectId);
         granted = res.ok;
         // Drain the body (a full premium.tar.gz on success) so we don't leave
         // it dangling - we only need the status, not the content.

package/cli/dist/utils/spinner.js

@@ -0,0 +1,39 @@
+import chalk from "chalk";
+const FRAMES = ["⠋", "⠙", "⠹", "⠸", "⠼", "⠴", "⠦", "⠧", "⠇", "⠏"];
+export function startSpinner(initialText) {
+    const stream = process.stderr;
+    const animate = stream.isTTY === true;
+    let frame = 0;
+    let text = initialText;
+    let timer;
+    const render = () => stream.write(`\r\x1b[2K${chalk.cyan(FRAMES[frame])} ${text}`);
+    if (animate) {
+        render();
+        timer = setInterval(() => {
+            frame = (frame + 1) % FRAMES.length;
+            render();
+        }, 80);
+    }
+    else {
+        stream.write(`- ${text}\n`);
+    }
+    const finish = (symbol, message) => {
+        if (timer)
+            clearInterval(timer);
+        stream.write(`${animate ? "\r\x1b[2K" : ""}${symbol} ${message ?? text}\n`);
+    };
+    return {
+        get text() {
+            return text;
+        },
+        set text(value) {
+            text = value;
+            if (!animate)
+                stream.write(`- ${text}\n`);
+        },
+        succeed: (message) => finish(chalk.green("✔"), message),
+        fail: (message) => finish(chalk.red("✖"), message),
+        warn: (message) => finish(chalk.yellow("⚠"), message),
+    };
+}
+//# sourceMappingURL=spinner.js.map

package/cli/package.json

@@ -1,7 +1,7 @@
 {
   "name": "tdk-cli-internal",
   "private": true,
-  "version": "1.3.53",
+  "version": "1.3.55",
   "description": "TDK CLI - Tilt Development Kit command line interface",
   "keywords": [
     "tdk",
@@ -58,7 +58,6 @@
     "handlebars": "^4.7.8",
     "ink": "^7.1.1",
     "ink-select-input": "^6.2.0",
-    "ora": "^9.4.1",
     "react": "^19.3.0"
   },
   "devDependencies": {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@tdk-landscape/tdk-cli-core",
-  "version": "1.3.53",
+  "version": "1.3.55",
   "description": "Run 100 microservices on a 16 GB laptop without Kubernetes. Scaffold services and run them locally with hot reload, built on Tilt.",
   "homepage": "https://tdk-landscape.github.io/tdk-website",
   "repository": {
@@ -18,6 +18,21 @@
     "tdk": "cli/bin/tdk.js",
     "tdk-cli": "cli/bin/tdk.js"
   },
+  "files": [
+    "Tiltfile",
+    "engine",
+    "!engine/docs",
+    "discovery",
+    "specs",
+    "ext",
+    "shared-platform-engineering/docker-templates",
+    "cli/bin",
+    "cli/dist/**/*.js",
+    "cli/templates",
+    "cli/package.json",
+    "cli/shared-platform-engineering/docker-templates",
+    "CHANGELOG.md"
+  ],
   "scripts": {
     "build": "cd cli && npm run build",
     "build:watch": "cd cli && npm run build:watch",
@@ -56,7 +71,6 @@
     "handlebars": "^4.7.8",
     "ink": "^7.1.1",
     "ink-select-input": "^6.2.0",
-    "ora": "^9.4.1",
     "react": "^19.3.0"
   },
   "devDependencies": {

package/.claude/skills/layer-autoresearch/SKILL.md

@@ -1,48 +0,0 @@
----
-name: layer-autoresearch
-description: Autonomous keep/discard experiment loop (after karpathy/autoresearch) that optimises TDK's L1-L4 Docker layers toward the north star of 100 services on a 16 GB machine. Use when asked to run autoresearch on the Docker layers or to optimise the golden/runtime layers experimentally.
----
-
-# Layer autoresearch
-
-Adapted from karpathy/autoresearch `program.md`. You are an autonomous researcher making the TDK runtime layers cheaper **without removing features**.
-
-## Setup (with the user, once)
-
-1. Agree a run tag (e.g. `sep25`). Create `git checkout -b autoresearch/<tag>` from `main`. The branch must be new.
-2. Warn the user: this workspace has an external tool that auto-commits and pushes working-tree edits. Ask them to pause it for the run, because experiment resets must not reach `origin/main`.
-3. Read the in-scope files in full:
-   - Editable: `engine/topologies/platform/docker/layers/*.star`, `engine/topologies/platform/docker/layers/prisma/*.star`, `engine/topologies/platform/docker/build/golden_image_dockerfile.star`, `engine/topologies/platform/docker/config/healthcheck.star`.
-   - Read-only ground truth: `scripts/autoresearch/layer-eval.sh`, `scripts/benchmark/container-scale.ts`, `tests/tilt-engine/test_runtime_container_footprint.py`, and the spec `openspec/specs/runtime-container-footprint` (or its change under `openspec/changes/`).
-4. Check that `../tdk-erp-system` exists with built images (`docker images | grep finance_`). If not, ask the human to run `tdk up` there once.
-5. Create an untracked `autoresearch-results.tsv` with the header `commit	mem_mib	image_mib	status	description`.
-6. Confirm with the user, then start.
-
-## Experiment
-
-Run `scripts/autoresearch/layer-eval.sh > run.log 2>&1` (about 5-10 minutes). Read the results with `grep -A20 '^---' run.log`.
-
-- **Primary metric: `mem_per_service_mib`, lower is better.** This is idle memory per real ERP service, and it is what limits 100 services on 16 GB.
-- **Tie-breaker:** if memory is within 0.5 MiB of the best, a lower `unique_per_service_mib` or `service_image_mib` wins, then simpler code.
-- **Hard constraints.** `status: ok` requires all 20 services healthy, zero crashes, and passing feature tests. Anything else is a discard, or a crash if it didn't run.
-- **Never** edit the eval harness, benchmark, tests or spec. Never remove a user-facing feature: Prisma, Infisical entrypoint, hugo-as-feature, healthchecks, signal handling. Don't add dependencies.
-
-Candidate ideas, from real measurements on 2026-09-25:
-- Duplicate `node_modules` copy in the L4 backend runtime (4.2 MB twice per service).
-- L1 installs `file`, `bash` and `openssl` into every runtime image (30 MB apk layer). Check what actually needs them first.
-- Bun runtime memory flags (e.g. `--smol`) in the resolved `CMD`.
-- Distroless or slimmer Bun base for L4.
-- Per-service unique layer size.
-
-## Loop (never stop until the human interrupts)
-
-1. Note the current commit.
-2. Change the editable files with one idea.
-3. `git commit -m "<idea>"`.
-4. Run the eval, redirected to `run.log` (don't flood context).
-5. If there's no `---` block, `tail -n 50 run.log`. Fix trivial mistakes, otherwise log `crash`.
-6. Append a row to `autoresearch-results.tsv` (untracked).
-7. If the metric improved and `status: ok`, keep the commit. Otherwise `git reset --hard HEAD~1`.
-8. An eval that runs longer than 20 minutes counts as a failure.
-
-The first run is always the unmodified baseline.

package/.claude/skills/tdk-troubleshoot/SKILL.md

@@ -1,222 +0,0 @@
----
-name: tdk-troubleshoot
-description: Diagnose and fix TDK (tdk-cli-core) local-dev problems with verified commands. Covers `tdk doctor`, `tdk up` or `tdk down` failing or hanging, "Docker daemon is not responding", red Tilt resources (pull access denied for golden images, missing shared-platform-engineering files, TS2688 bun types, run-only "No such image"), Postgres crash loops, services never reaching healthy, a machine overloaded by many services, Docker image size vs memory questions, and benchmarking how many services fit on a laptop. Use this whenever someone works in tdk-cli-core or a TDK project (tdk-erp-system, tdk-saas-starter, tdk-restaurant-example, auth-user) and anything about tdk, Tilt, or Docker is broken, slow, or being measured, even if they never say "troubleshoot".
----
-
-# TDK troubleshooting
-
-This skill comes from a long session on 2026-09-25. It brought `tdk-erp-system` (107 services) up, measured it, and wasted a lot of the user's time along the way. Everything below marked **measured** or **verified** was run on the user's 16 GB MacBook Air (Docker VM: 8 CPUs, 7,934 MiB). Anything else is labelled as unknown.
-
-## How to work (the expensive lessons)
-
-- **Say what you measured, what you estimated, and what you don't know, in that order.** Most of the frustration came from confident claims that a later measurement contradicted, such as "memory is ~16 MiB/container" (`docker stats`, which undercounts) and "112 s boot" (actually the launcher script). "I don't know yet, here is how I'd find out" is a good answer.
-- **Check machine load before blaming Docker, Tilt or the code.** An overloaded Mac makes every tool look broken.
-- **Before anything that runs longer than about 5 minutes or starts dozens of containers, say so and give an estimate.** A full ERP `tdk up` froze this machine once. Ask first.
-- **Give short status lines while waiting.** Silence during long builds reads as "nothing works".
-- **Don't polish a proxy metric.** Shrinking images didn't touch the real bottleneck. Ask what actually hurts (time, CPU, a freeze) and measure that.
-
-## First 60 seconds: triage
-
-```bash
-sysctl -n vm.loadavg; top -l 1 -n 0 | grep -E "CPU usage|PhysMem"
-time docker ps -q | wc -l
-pgrep -fl "tilt up"
-docker info --format 'CPUs={{.NCPU}} MemTotal={{.MemTotal}}'
-```
-
-- **`docker ps` taking more than about 5 s means overload, not breakage.** Measured: 6–13 s with 110 ERP containers plus Tilt running, load average 28–43, 99 MB free RAM. `tdk doctor` and `tdk down` both fail their own 10 s Docker check in that state.
-- **A `tilt up` process still running recreates any container you `docker stop`** within seconds. Stop Tilt first.
-- **Other TDK projects share the `*-autogenerated-*` container naming** (for example kitchen, guest, operations and auth from the restaurant and auth projects). Filter by stack name before stopping anything.
-
-## Symptoms, causes and fixes (verified)
-
-### "Docker daemon is not responding (`docker ps` hung for 10s)"
-
-**Cause:** overload, as above. `tdk down` is blocked by the same check.
-
-**Fix:** stop Tilt, then stop the project's containers directly.
-
-```bash
-pkill -TERM -f "tilt up -f $PWD/.tdk/.tdk-out/Tiltfile"
-docker ps --format '{{.Names}}' | grep -E '^(finance|hr|sales|inventory|manufacturing|supply_chain|analytics)-autogenerated-' | xargs docker stop
-```
-
-### Postgres restarting with "Database is uninitialized and superuser password is not specified"
-
-**Cause:** the container was created while `DB_PASSWORD` was empty. Environment variables are fixed when a container is created, so fixing `.env` later doesn't help.
-
-**Check:**
-
-```bash
-docker inspect <project>_postgres --format '{{range .Config.Env}}{{println .}}{{end}}' | grep POSTGRES_PASSWORD
-```
-
-**Fix:** recreate the container (Tilt or compose `up` recreates it). The data volume survives.
-
-### Tilt build error `pull access denied ... docker.io/library/<project>-l4-backend:latest`
-
-**Cause:** the golden layers aren't built yet (the `golden-layers-build` resource is still running).
-
-**Fix:** wait for it to finish. Tilt does **not** retry resources that failed before it finished, so trigger every errored resource yourself.
-
-```bash
-tilt get uiresources -o json | python3 -c 'import json,sys; [print(i["metadata"]["name"]) for i in json.load(sys.stdin)["items"] if i.get("status",{}).get("updateStatus")=="error"]' | xargs -n1 tilt trigger
-```
-
-### `*-run-only` resources fail with `No such image: <stack>_<svc>:dev`
-
-**Cause:** they ran `docker compose up --no-build` before the image existed.
-
-**Fix:** once the image builds, `tilt trigger` them.
-
-### Missing generated files in the build context
-
-The build fails with `"/shared-platform-engineering/docker-templates/<x>.sh": not found` or `"/package.json": not found`.
-
-**Cause:** the project is missing its generated runtime assets.
-
-**Fix:**
-- `tdk project --yes` copies `shared-platform-engineering/docker-templates` (verified).
-- If the root `package.json` is still missing, add a Bun workspace manifest. This is what fixed ERP:
-
-  ```json
-  { "name": "<project>", "private": true, "type": "module", "workspaces": ["services/*/*"] }
-  ```
-
-- `tdk doctor` now reports both (`checkGeneratedProjectRuntimeAssets`).
-
-### `bun run build` fails with `TS2688: Cannot find type definition file for 'bun'`
-
-**Cause:** the generated tsconfig sets `"types": ["bun"]`, but the service's `package.json` has no `@types/bun`.
-
-**Fix:** add `"@types/bun": "^1.4.2"` to `devDependencies`. `tdk doctor` now reports this (`checkTypeScriptTypeDependencies`).
-
-### `tdk up <stack>` queues every stack
-
-**Observed, not root-caused:** `tdk up finance` left 129 resources pending across all stacks.
-
-**Protect the machine:** check the counts, then disable the other stacks.
-
-```bash
-tilt get uiresources -o json | python3 -c 'import json,sys,collections; print(collections.Counter(i.get("status",{}).get("updateStatus") for i in json.load(sys.stdin)["items"]))'
-tilt disable <other-stack-resource> <...>
-```
-
-### Engine edits have no effect
-
-**Cause:** projects run a vendored copy of the engine at `.tdk/.tdk-out/tdk-cli-ext/`. The installed `/usr/local/bin/tdk` vendors **its own bundled engine**, so it can silently overwrite your local one.
-
-**Fix:** re-vendor from your local checkout, then check the copy matches.
-
-```bash
-(cd <core>/cli && bun run build)
-TDK_EXTENSION_SOURCE=<core> node <core>/cli/bin/tdk.js project --yes
-diff -rq <core>/engine/topologies/platform/docker .tdk/.tdk-out/tdk-cli-ext/engine/topologies/platform/docker
-```
-
-### Reading Tilt state
-
-- Use the CLI. The HTTP API (`localhost:10350/api/view`) returns 403 "missing session token".
-- `tilt get uiresources <name> -o json` shows a resource's state. **`buildHistory[0]` is the newest build**; reading `[-1]` shows a stale error and misleads you.
-- `tilt logs <resource>` gives the full build log.
-
-## ERP project layout
-
-| Thing | Value |
-|---|---|
-| Service manifests | `services/<stack>/<svc>/service.json` |
-| Image names | `<stack>_<svc>:dev` |
-| Compose project | `<stack>-autogenerated` |
-| Compose file | `services/<stack>/.autogenerated/docker-compose.app.autogenerated.yml` |
-| Postgres | `services/platform/database-management/docker-compose.yml` |
-| Traefik | `.tdk/.tdk-out/docker-compose.traefik.yml` |
-| Databases | `<project>_<stack>`, created with `createdb` |
-| Golden images | `<project>-l1`, `-l2`, `-l3-*`, `-l4-*` |
-
-## Measuring without fooling yourself
-
-### Image size is disk, not RAM
-
-- `docker images` counts shared layers once per image. Real disk use is `docker system df`. The 107 ERP images add up to 26 GB listed, but all 151 images on the machine together use 6 GB on disk.
-- See what fills an image, layer by layer:
-
-  ```bash
-  docker history <img> --format '{{.Size}}\t{{.CreatedBy}}'
-  ```
-
-- **Measured:** ERP backends are 176–276 MB each, but only 4.5–8.8 MB is service-specific. The rest is shared: Bun binary 93 MB, Alpine 9 MB, L1 packages 30 MB.
-- **Measured:** `auth_auth-api-backend:dev` is 826 MB on disk, yet uses 33 MiB of RAM when running. Of the 826 MB, two copies of `node_modules` take 199 MB each, and hugo takes 57 MB. The duplicate-copy fix is only on branch `autoresearch/sep25`. The hugo removal is on `main`. Both need a rebuild to take effect.
-
-### RAM: `docker stats` undercounts
-
-It leaves out Docker's per-container overhead in the VM (containerd shims and the init process). Use the change in the Docker VM's own memory instead:
-
-```bash
-docker run --rm alpine awk '/MemTotal/{t=$2}/MemAvailable/{a=$2}END{printf "%d MiB used\n",(t-a)/1024}' /proc/meminfo
-```
-
-- **Measured:** 100 idle ERP containers cost **2,076 MiB real (about 21 MiB each)**. `docker stats` reported 1,693 MiB for the same containers.
-- The VM measurement is noisy for small counts: the same 20-container setup read 442 MiB one time and 214 MiB the next. Use 100 containers, or repeat the run and report the range.
-
-### Time: start containers in parallel, as Tilt does
-
-A serial `docker run` loop measures the launcher, not the services. For parallel starts on macOS:
-
-```bash
-tr '\n' '\0' < cmds.txt | xargs -0 -n1 -P8 sh -c
-```
-
-- **Measured:** 100 ERP containers were all healthy in **31.7 s** starting 8 at a time, with 0 crashes. Starting the containers took 26.6 s of that.
-- The website claims "full boot in under 5 seconds". Measured, that only holds for about 5 services (4.5 s).
-
-### North-star math: 100 services in 16 GB
-
-(Docker VM MemTotal − 512 MiB for infrastructure) ÷ 100 = the per-service budget. On this Mac that's (7,934 − 512) ÷ 100 ≈ **74 MiB per service**. The measured 21 MiB fits, but only for idle containers answering `/health`. It hasn't been measured under real load.
-
-## Tools in this repo and how far to trust them
-
-| Tool | Status |
-|---|---|
-| `bun scripts/benchmark/container-scale.ts --synthetic` | **Verified** for 5 to 100 containers. Starts containers serially, so "all healthy" is about the launch time. |
-| `container-scale.ts` default (compose) mode | **Verified at tier 5** (2026-09-26): real generated compose files, real Postgres, real Traefik, 5/5 requests through Traefik returned 200, all healthy in 4.9s. Not yet run at 100 — that's the one that answers the north star. Its first run hung indefinitely (`Bun.spawn()` + a `Bun.sleepSync()` poll on `exitCode` never observes the exit, because `sleepSync` blocks the event loop Bun needs to record it) — fixed by launching with `spawnSync` instead. If you see a `container-scale.ts` run sit for minutes with 0% CPU while its containers are already healthy, this bug is back; check for `Bun.spawn` + `sleepSync` polling anywhere in the file. |
-| `scripts/autoresearch/layer-eval.sh` with the `layer-autoresearch` skill | **Verified** (4 runs). Run it from a worktree outside `~/Developer/Codex`. |
-| `scripts/measure-idle-footprint.sh <container>` | Written but **never run**. |
-| `tilt alpha tiltfile-result -f <Tiltfile>` | Runs Starlark without starting anything. `print` output is swallowed, so return data with `fail('RESULT' + encode_json(r))`. `load()` needs a literal path. |
-| `tests/tilt-engine/test_runtime_container_footprint.py` | Runs the real generators through Tilt. |
-
-## Environment traps
-
-- **`.tdk/.project-id` is not gitignored by default and is easy to accidentally stage.** It's created the first time anything checks a Premium license (`getOrCreateProjectId` in `cli/src/generator/extension-fetch.ts`) - a random UUID sent alongside `TDK_LICENSE_KEY` to the license server for per-project tracking, not itself a secret credential, but it's local machine state that has no business in a shared repo. Found staged (`git status`, not yet committed - caught before it reached `origin/main`) in `tdk-erp-system` on 2026-09-26; `tdk-saas-starter` and `tdk-restaurant-example` had the same `.gitignore` gap with no file yet; `tdk-user-management` has **no `.gitignore` at all** (currently harmless - only 35 minimal tracked files, nothing sensitive - but unprotected the moment real development starts there). The CLI has no `.gitignore` template of its own to fix at the source (`tdk project` doesn't generate one; each starter repo ships its own) - check every project's `.gitignore` for `.tdk/.project-id` individually, and `git status`/`git log --all -- .tdk/.project-id` before assuming it's fine.
-
-- **Auto-commit tool.** Something outside Claude commits and pushes edits in `~/Developer/Codex/*` repos to `origin/main` within about a minute, with messages like "skill" or "specs". Do experiments in a worktree outside that folder:
-
-  ```bash
-  git worktree add ~/Developer/<name> <branch>
-  ```
-
-- **macOS shell:**
-  - There's no `timeout` command.
-  - `xargs -I` has a 255-character limit, so use the `-0` form above.
-  - System `python3` is 3.9: add `from __future__ import annotations` before using `X | None` types.
-  - Bash is version 3.2.
-- **Lint only the files you touched:**
-
-  ```bash
-  cd cli && ./node_modules/.bin/biome check <files>
-  ```
-
-  `bun run lint -- <files>` still lints the whole repo, which has many pre-existing errors.
-- **Failures that aren't yours:**
-  - pytest `test_docker_generator_bugs.py::test_expose_line_must_be_numeric_port` and `test_health_endpoints.py::test_overall_health_endpoint_structure` also fail on the unmodified code.
-  - vitest `saas-starter-integration` and `stack-features-e2e` time out when Docker is busy.
-
-## Resolved since the first version of this skill
-
-- **`tdk up <stack>` queuing every stack — fixed and verified (2026-09-26).** `tdk up finance` computed the right 16-service list but passed it to Tilt as bare positional args. The generated Tiltfile's focus filter (`Config.apply_focus` / `apply_focus_filter` in `profiles.star`) only reads the `--focus` flag - the positional-args catch-all it also defines (`cfg['args']`) is never read anywhere. So every stack-scoped `tdk up` silently fell back to Tilt's default "pre-alpha" phase and enabled every stack in it (verified: 247 enabled resources instead of 16-40). Fix: `buildTiltUpArgs` (`cli/src/utils/tilt.ts`) now passes `--focus=<stackName>`, reusing the Tiltfile's own dependency-aware domain expansion. **Argument order matters**: `--focus=...` must come after a `--` separator (`tilt up -f <path> -- --focus=finance <names>`) - `tilt up` rejects `--focus` as an unrecognized top-level flag otherwise (`tilt up --help` lists its real flags; custom Tiltfile config flags only reach `config.parse()` via `--`). Verified end-to-end: `tilt get uiresources` showed 402 Disabled / 24 Enabled for `tdk up finance` after the fix, and the 24 enabled were exactly finance's services plus required infra.
-
-- **What actually overloads a real full `tdk up` at 100+ services — tested and it held (2026-09-26).** Ran a real, uncapped `tdk up` (no stack filter, all 107 services, Tilt doing real builds and reconciliation - not the synthetic/capped benchmark) with a self-killing watchdog sampling load/free-memory/`docker ps` latency every 5s. Result: **110/110 containers reached healthy, zero crashes, zero danger-threshold strikes**, over an 18-minute run. Load peaked around 20 during the busiest build phase (~20-30 containers starting at once) and then *settled back down* to 11-16 as more services came online, finishing at 11.45 with all 110 up. `docker ps` occasionally spiked to 2-6s under load but never approached the 10s `tdk doctor` timeout for long. This is the same scenario that froze the machine on 2026-09-25 (load 28-43, 99 MB free, `docker ps` 6-13s) - it did not recur. Caveat: this is one run on one machine state, and it isn't certain which fix (or whether the host simply had less competing load this time) made the difference; the single-process-CMD image rebuild only covered a minority of services (finance + a couple of supply_chain ones) at the time of this run, so a full image rebuild wasn't a factor. Re-run with the watchdog pattern above (`sysctl -n vm.loadavg`, `vm_stat` free pages, timed `docker ps`) before trusting a "it's fine now" claim on a different machine or after further engine changes.
-
-## Still unknown
-
-- **Whether Bun `--smol` (`BUN_OPTIONS=--smol`) saves memory.** Bun does read the variable, but the A/B test was inconclusive.
-- **Why auth's production `node_modules` is 199 MB.**

package/.github/ISSUE_TEMPLATE/bug_report.yml

@@ -1,40 +0,0 @@
-name: Bug report
-description: Something in tdk does not work as expected
-labels: [bug]
-body:
-  - type: textarea
-    id: what-happened
-    attributes:
-      label: What happened?
-      description: What did you run, what did you expect, and what happened instead?
-    validations:
-      required: true
-  - type: textarea
-    id: repro
-    attributes:
-      label: Steps to reproduce
-      placeholder: |
-        1. tdk project --yes
-        2. tdk up api
-        3. ...
-    validations:
-      required: true
-  - type: textarea
-    id: doctor
-    attributes:
-      label: Output of `tdk doctor`
-      render: shell
-  - type: input
-    id: version
-    attributes:
-      label: TDK version
-      description: Output of `tdk --version`
-    validations:
-      required: true
-  - type: dropdown
-    id: os
-    attributes:
-      label: Operating system
-      options: [macOS (Apple Silicon), macOS (Intel), Linux, Windows (WSL), Other]
-    validations:
-      required: true

package/.github/ISSUE_TEMPLATE/config.yml

@@ -1,11 +0,0 @@
-blank_issues_enabled: true
-contact_links:
-  - name: Request a Premium license (form)
-    url: https://tdk-landscape.github.io/tdk-website/#waitlist
-    about: Private request form on the TDK website
-  - name: Documentation
-    url: https://tdk-landscape.github.io/tdk-website
-    about: Guides, quickstart, and examples
-  - name: Report a security vulnerability
-    url: https://github.com/tdk-landscape/tdk-cli-core/security/advisories/new
-    about: Please report security issues privately

package/.github/ISSUE_TEMPLATE/feature_request.yml

@@ -1,18 +0,0 @@
-name: Feature request
-description: Suggest an idea or improvement for TDK
-labels: [enhancement]
-body:
-  - type: textarea
-    id: problem
-    attributes:
-      label: What problem are you trying to solve?
-    validations:
-      required: true
-  - type: textarea
-    id: solution
-    attributes:
-      label: What would you like TDK to do?
-  - type: textarea
-    id: alternatives
-    attributes:
-      label: What do you do today instead?