@podosoft/podokit 0.17.4 → 1.0.1

package/dist/templates/todo/dot-agents/skills/podokit-deploy/SKILL.md

@@ -1,65 +0,0 @@
----
-name: podokit-deploy
-description: Plan, inspect, apply, verify, and roll back PodoKit releases with an explicit deployment profile and confirmation hash, on Kubernetes or Docker Compose. Use when an agent needs to initialize a .podokit/deploy profile, diagnose a target, preview a release, perform an approved deployment, inspect rollout state, verify public endpoints, or prepare a rollback.
----
-
-# Deploy a PodoKit application
-
-A profile records which driver it uses, so every command below is the same for both.
-Read the profile's `driver` first and say which one you are operating.
-
-| Driver | Target | Use it when |
-| --- | --- | --- |
-| `kubernetes-helm` | a cluster context and namespace | you already run a cluster, or you need more than one node, cluster-managed rollouts, or per-workload scaling |
-| `docker-compose` | one Docker host, local or over `ssh://` | one machine is the whole deployment and a reverse proxy in front of it terminates TLS |
-
-1. Run `npx @podosoft/podokit status`, `npx @podosoft/podokit diff`, and `npx @podosoft/podokit doctor`. Stop if managed-file conflicts or unsupported framework versions could make the image unreliable.
-2. Read [references/profile.md](references/profile.md) before creating or changing a deployment profile.
-3. Make sure the images exist for that tag. Read [references/release.md](references/release.md): tagging `vX.Y.Z` runs the release workflow, which builds and pushes both images and stops there. Never apply a release whose images were not published.
-4. Run `npx @podosoft/podokit deploy doctor --profile <name>`. Resolve every failure without printing secret values.
-5. Run `npx @podosoft/podokit deploy plan --profile <name> --release <stable-semver> --json`.
-6. Show the user the driver, the target (context plus namespace and Helm release, or Docker context plus Compose project), the fingerprint result, the exact image digests, the current revision, the actions, the migration warning, and the plan hash.
-7. Do not apply until the user explicitly approves that exact plan.
-8. Apply with `npx @podosoft/podokit deploy apply --profile <name> --release <stable-semver> --confirm <plan-hash>`.
-9. Run `npx @podosoft/podokit deploy status --profile <name> --json` and `npx @podosoft/podokit deploy verify --profile <name> --json`.
-10. Report the exact images, the revision, running replicas, restart totals, and the verification result. Report `syncDrift` too: a non-empty value means containers are running locally synced artifacts and the release tag does not describe what is serving.
-
-## Iterating against a deployment is a different command
-
-If the user is changing code and wants to see it on the deployment, a release is the
-wrong loop — it rebuilds and republishes to move a few megabytes of compiled output.
-Use the `podokit-deploy-fast` skill (`podo deploy sync`, docker-compose driver only).
-Reach for a release when the change needs a migration, changes runtime dependencies,
-or is going to real users.
-
-## The migration runs against the release that is still serving
-
-Both drivers run the migration **before** the new containers start, and both keep the
-previous release serving while the new one rolls out. So a migration must be
-compatible with the code already running:
-
-- Additive changes are safe: new tables, new nullable columns, new indexes.
-- Dropping or renaming a column, or tightening a constraint, breaks the running
-  release the moment the migration commits — before any new code is live.
-- Destructive changes belong in a **second** release, after the code that stopped
-  using the column has fully rolled out.
-
-Rollback does not reverse migrations on either driver. If an older image cannot read
-the current schema, roll forward instead.
-
-## Rollback
-
-Read [references/rollback.md](references/rollback.md), preview the target revision
-without `--confirm`, show the new plan hash, and obtain explicit approval.
-
-The compose driver can only reproduce a revision whose rendered project still matches
-the current profile byte for byte; if the profile changed since, it refuses and tells
-you to roll forward.
-
-## Boundary
-
-Never create or rotate cluster credentials, registry credentials, DNS records,
-virtual machines, Kubernetes Secrets, env files on a deployment host, TLS
-certificates, or backup repositories. Never put a password, token, private key,
-connection URL containing credentials, or secret value in a profile, a command
-argument, a log, or a report.

package/dist/templates/todo/dot-agents/skills/podokit-deploy/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "PodoKit Deploy"
-  short_description: "Plan and verify safe Kubernetes releases"
-  default_prompt: "Use $podokit-deploy to inspect and plan this PodoKit Kubernetes release safely."

package/dist/templates/todo/dot-agents/skills/podokit-deploy/references/profile.md

@@ -1,75 +0,0 @@
-# Deployment profile
-
-The profile at `.podokit/deploy/<name>.json` is application-owned and contains no Secret values.
-
-## kubernetes-helm (default)
-
-Initialize it with an explicit kubeconfig context:
-
-```bash
-npx @podosoft/podokit deploy init --profile production --context production --host app.example.com
-```
-
-Review the target, immutable API/web repositories, exposure, workloads, dependency modes, API/optional web Secret names and required keys, non-sensitive runtime configuration, and verification checks before planning.
-
-The cluster namespace and referenced Secrets must already exist. PodoKit asks `kubectl` to output only Secret key names and never prints or stores their values; the Kubernetes client still materializes the Secret while evaluating that output.
-
-Required keys:
-
-| Secret | Required keys |
-| --- | --- |
-| API | Profile-declared keys plus enabled dependency connection keys: `POSTGRES_USER`, `POSTGRES_PASSWORD`, `POSTGRES_DB`, `REDIS_PASSWORD`, `S3_ACCESS_KEY_ID`, `S3_SECRET_ACCESS_KEY` |
-| web | Only explicitly declared web keys; omitted by default |
-| PostgreSQL dependency | `POSTGRES_USER`, `POSTGRES_PASSWORD`, `POSTGRES_DB` |
-| Redis dependency | `REDIS_PASSWORD` |
-| Object storage dependency | `MINIO_ROOT_USER`, `MINIO_ROOT_PASSWORD`, `S3_ACCESS_KEY_ID`, `S3_SECRET_ACCESS_KEY` |
-| image pull | A `kubernetes.io/dockerconfigjson` Secret |
-
-Use `inCluster` when the generated Helm release should manage a dependency, `external` when application configuration points to an existing service, and `disabled` only when the application does not require it.
-
-Use the same stable SemVer tag for API and web. `latest`, branch tags, and empty tags are rejected. Planning resolves every deployed tag to an immutable registry digest through Docker Buildx.
-
-## docker-compose
-
-Initialize it with an explicit Docker context. The context may be local or `ssh://`,
-and it is pinned by a fingerprint of the endpoint plus the daemon ID, so repointing
-it at a different host invalidates the profile instead of deploying somewhere else.
-
-```bash
-npx @podosoft/podokit deploy init \
-  --profile production \
-  --driver docker-compose \
-  --context production \
-  --host app.example.com \
-  --secrets-dir /etc/podokit/example-app
-```
-
-The fields that differ from the Kubernetes driver:
-
-- `target`: Docker context, endpoint fingerprint, Compose project name
-- `exposure`: `bindAddress` and `port` published from the web service. It defaults to
-  `127.0.0.1`, because the expected front door is a reverse proxy on the same host —
-  binding every interface publishes the app before TLS exists
-- `workloads`: replicas plus Compose `cpus` and `memory` limits
-- `dependencies`: `managed`, `external`, or `disabled`, each with a named Docker
-  volume and the path of its env file on the target host
-- `secrets`: env-file paths and required key names, plus `registryLogin`
-
-Credentials live in env files **on the target host**, never in the profile and never
-in the rendered Compose project. The doctor reads only the key names, in a throwaway
-container that mounts the file read-only. Create those files with the host's own
-secret tooling before deploying; PodoKit does not write them.
-
-Required keys:
-
-| Env file | Required keys |
-| --- | --- |
-| API | Profile-declared keys plus enabled dependency connection keys: `POSTGRES_USER`, `POSTGRES_PASSWORD`, `POSTGRES_DB`, `REDIS_PASSWORD`, `S3_ACCESS_KEY_ID`, `S3_SECRET_ACCESS_KEY` |
-| web | Only explicitly declared web keys; omitted by default |
-| PostgreSQL dependency | `POSTGRES_USER`, `POSTGRES_PASSWORD`, `POSTGRES_DB` |
-| Redis dependency | `REDIS_PASSWORD` |
-| Object storage dependency | `MINIO_ROOT_USER`, `MINIO_ROOT_PASSWORD`, `S3_ACCESS_KEY_ID`, `S3_SECRET_ACCESS_KEY` |
-
-Data volumes are declared `external`, so `docker compose down -v` cannot delete the
-database. Editing an env file changes the containers' rollout label, so the next
-apply actually restarts them instead of leaving stale environment values running.

package/dist/templates/todo/dot-agents/skills/podokit-deploy/references/release.md

@@ -1,64 +0,0 @@
-# Publishing the images a release deploys
-
-`podo deploy` consumes images. Building them is `.github/workflows/release.yml`,
-which triggers on a `v*.*.*` tag, verifies the commit, builds both images from the
-repository root, and pushes them under that one tag. It does not roll out.
-
-```bash
-git tag v1.2.3
-git push origin v1.2.3
-```
-
-Then plan and apply as the main skill describes. `podo deploy plan` resolves the tag
-to an immutable digest, so a tag whose images were never pushed fails there rather
-than half way through a rollout.
-
-## Before the first tag: check the runner
-
-**GitHub-hosted runners are free for public repositories only.** In a private
-repository every minute is metered against the account's included Actions minutes and
-billed beyond them, and image builds are usually the most expensive job a project
-runs. A self-hosted runner consumes no Actions minutes at all.
-
-The workflow reads the choice from a variable, so it is a setting rather than an edit:
-
-| Variable | Unset | Notes |
-| --- | --- | --- |
-| `PODOKIT_RUNNER` | `["ubuntu-latest"]` | JSON array of labels. Self-hosted example: `["self-hosted","Linux","X64"]` |
-| `PODOKIT_DEPLOY_PROFILE` | `production` | which `.podokit/deploy/<name>.json` names the image repositories |
-| `PODOKIT_IMAGE_PLATFORM` | `linux/amd64` | the architecture the **deployment target** runs, not the runner's |
-
-Nothing warns when a private repository is still on the default: the workflow
-succeeds either way and the difference appears on a bill. **When asked to set up
-releases, check the repository's visibility first and say which case it is.**
-
-`PODOKIT_IMAGE_PLATFORM` is the other one worth stating out loud. Building for the
-wrong architecture produces `exec format error` at rollout — after the migration has
-already run — and building for the right one on a runner of a different architecture
-works but runs under emulation, which is slow enough to be mistaken for a problem
-with Docker.
-
-## Secrets
-
-`REGISTRY_USERNAME` and `REGISTRY_PASSWORD`, for the registry named by the profile's
-`release.apiRepository`. A robot or deploy account is enough for pushing, but some
-registries do not let a robot **create** a repository — push the first tag of a new
-repository with an account that can, or create the repository in the registry first.
-
-Never print either value, and never put one in a profile, a command argument, or a
-report.
-
-## Building by hand
-
-Only when a tag is not the right trigger. Build for the target's architecture, tag
-both images identically, and push before planning:
-
-```bash
-docker build --platform linux/amd64 -f apps/api/Dockerfile -t <api-repository>:v1.2.3 .
-docker build --platform linux/amd64 -f apps/web/Dockerfile -t <web-repository>:v1.2.3 .
-docker push <api-repository>:v1.2.3
-docker push <web-repository>:v1.2.3
-```
-
-A bare local tag cannot be deployed: it does not match the profile's stable SemVer
-pattern and cannot be resolved to a digest.

package/dist/templates/todo/dot-agents/skills/podokit-deploy/references/rollback.md

@@ -1,5 +0,0 @@
-# Application rollback
-
-Preview the selected revision without `--confirm`, show the resulting plan hash, and obtain explicit approval before rerunning the command with that hash.
-
-Rollback changes only the application Helm release. It does not reverse database migrations, change the dependency release, delete PersistentVolumeClaims, or delete Secrets. If the old application is incompatible with the current database schema, prepare a forward fix instead.

package/dist/templates/todo/dot-agents/skills/podokit-deploy-fast/SKILL.md

@@ -1,92 +0,0 @@
----
-name: podokit-deploy-fast
-description: Push locally built artifacts into a running Docker Compose deployment and restart it, without building or publishing an image. Use when iterating on code against a deployed environment and a full release round trip is too slow. Not for releases, migrations, dependency changes, or anything going to real users.
----
-
-# Sync code into a running deployment
-
-`podo deploy sync` copies this project's build output into the containers that are
-already running and restarts them. `docker-compose` driver only — read the profile's
-`driver` first and stop if it is `kubernetes-helm`, where the equivalent would have
-to reach every node and would stop being a shortcut.
-
-```bash
-npx @podosoft/podokit deploy sync --profile <name> --build
-```
-
-## Say what this does before doing it
-
-It is not a release, and the user has to understand three consequences before you run
-it:
-
-1. **The deployment will run code its image tag does not describe.** A marker file
-   records the sync and `podo deploy status` reports it under `syncDrift`.
-2. **Every connection the restarted containers hold is dropped** — WebSocket sessions,
-   in-flight requests, anything attached.
-3. **It disappears on the next release.** Container writable layers do not survive
-   recreation, so `podo deploy apply` restores the image with no cleanup step. That is
-   the property that makes this safe; do not build anything that depends on the copy
-   persisting.
-
-## When NOT to use it
-
-Use a release instead — build the images and `podo deploy apply` — when any of these
-is true. The first three are refusals the command makes itself; the last two it
-cannot detect, which is why they are your job.
-
-| Situation | Why |
-| --- | --- |
-| runtime dependencies changed | the container's `node_modules` was installed `--omit=dev` from the old manifest, so the new code imports something that is not there |
-| a release holds the deployment lock | an apply is in progress |
-| nothing is running for that project | there is no container to copy into |
-| **the change needs a migration** | sync never migrates, and a migration belongs with the release whose code needs it |
-| **the change is going to real users** | nothing is pushed, so nothing is reproducible from it |
-
-## Procedure
-
-1. Read the profile's `driver`. Stop unless it is `docker-compose`.
-2. Tell the user what will restart and that connections drop. Get agreement if anyone
-   is using the deployment.
-3. Run with `--build` unless the project is already built. `--build` compiles in the
-   order the images do — every `packages/*` before the apps — because a root build
-   script runs workspaces in manifest order and an app listed first would compile
-   against a workspace package's previous output.
-4. Report what was copied, which containers restarted, and that the deployment is now
-   in sync drift.
-5. Verify against the running deployment, not against the build: request a path the
-   change affects. If part of the build output is excluded (below), check one of
-   those paths too — that is the failure this exclusion exists to prevent, and it
-   does not make the page look broken.
-
-## Restoring the image
-
-```bash
-npx @podosoft/podokit deploy sync --profile <name> --revert
-```
-
-This recreates the containers from the Compose project **already on the target**,
-which is the description of what was actually applied — not a fresh render, which
-would reproduce the profile as it is now.
-
-A release does the same thing as a side effect, so `--revert` is for abandoning a
-sync, not a required cleanup step.
-
-## Excluding part of the build output
-
-Some of a build output can come from a toolchain the developer's machine does not
-have. Overwriting that part replaces real artifacts with an index of artifacts that
-are no longer there, and the application keeps serving pages while the missing files
-404 — so nothing looks broken. Those paths belong in the profile:
-
-```json
-{ "sync": { "exclude": ["apps/web/build/static-assets/generated"] } }
-```
-
-If you find yourself about to sync over something this machine cannot rebuild, add it
-here rather than remembering not to. `--clean` refuses while an exclude sits beneath
-a synced path, for the same reason.
-
-## Boundary
-
-Never use this to ship. Never run migrations alongside it. Never create or rotate
-credentials, and never print a secret value.

package/dist/templates/todo/dot-claude/skills/podokit-add-locale/SKILL.md

@@ -1,63 +0,0 @@
----
-name: podokit-add-locale
-description: Add, translate, validate, activate, or troubleshoot a JSON locale in a PodoKit-generated SvelteKit app. Use when a user asks to add a language, split or edit locale JSON, check translation coverage or placeholders, configure fallback behavior, or verify locale changes through Vite HMR.
----
-
-# PodoKit Add Locale
-
-Add languages through the PodoKit locale commands and the app-owned JSON catalog. Keep module catalogs managed so `podo update` can continue to update them.
-
-## Workflow
-
-1. Inspect the existing locale state.
-
-   ```sh
-   podo locale list
-   ```
-
-2. Add a canonical BCP 47 language tag. Set `--direction rtl` only for right-to-left languages.
-
-   ```sh
-   podo locale add pt-BR --name "Português (Brasil)"
-   ```
-
-3. Read [references/catalog-format.md](references/catalog-format.md), then translate the new app-owned file at `apps/web/src/lib/i18n/catalogs/app/<locale>.json`.
-
-4. Validate key coverage, JSON value types, and interpolation placeholders.
-
-   ```sh
-   podo locale validate pt-BR
-   ```
-
-5. Activate the locale. Partial catalogs are permitted because runtime fallback fills missing keys, but report the coverage percentage to the user.
-
-   ```sh
-   podo locale activate pt-BR
-   ```
-
-6. Run the app with its documented container-based development command. Verify the language switch, one complete key, one fallback key, and locale persistence. Editing an existing JSON file must update through Vite HMR without restarting the container. Adding a new locale file may trigger an automatic full-page reload.
-
-## Rules
-
-- Treat `en` as the stable final fallback and never deactivate it.
-- Preserve placeholders exactly. For example, translate `Hello {name}` without renaming or removing `{name}`.
-- Put product-specific copy only in `catalogs/app/`. Do not edit `catalogs/admin-dashboard/` or other module catalogs directly.
-- Keep locale definition filenames identical to their canonical codes, including case such as `pt-BR.json`.
-- Do not activate a locale definition before its JSON parses and `podo locale validate` succeeds.
-- Do not use the UI message catalogs for user-authored records. Dynamic content needs locale-aware records and a separate publication/fallback policy.
-- When deactivating a locale, preserve its files so it can be reactivated without losing translations.
-
-## Fallback And Site Default
-
-The message runtime resolves missing keys in this order: selected locale, configured site default, then English. The site default is an administrator choice, not a build-time constant. Changing it must not delete or rewrite catalogs.
-
-If a requested language is unsupported or inactive, resolve it to the configured site default. Keep localized URL and SEO behavior in the consuming app; the catalogs provide translated strings but do not define routing policy.
-
-## Completion Checklist
-
-- `podo locale validate` succeeds for every active locale.
-- The new locale definition is active and has the intended display name and direction.
-- App-owned JSON contains the new product copy; managed module catalogs remain untouched.
-- Development edits update without a container restart.
-- Automated tests cover selection, fallback, placeholders, and at least one incomplete catalog.
-- User-facing locale setup or routing documentation is updated when behavior changes.

package/dist/templates/todo/dot-claude/skills/podokit-add-locale/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "PodoKit Locale Setup"
-  short_description: "Add and validate JSON locale catalogs safely"
-  default_prompt: "Use $podokit-add-locale to add, validate, activate, and test a new JSON locale in this PodoKit app."

package/dist/templates/todo/dot-claude/skills/podokit-add-locale/references/catalog-format.md

@@ -1,49 +0,0 @@
-# JSON Catalog Format
-
-## Directory Layout
-
-```text
-apps/web/src/lib/i18n/
-├── locales/
-│   ├── en.json
-│   ├── ko.json
-│   └── pt-BR.json
-└── catalogs/
-    ├── admin-dashboard/  # PodoKit-managed module messages
-    ├── blog/             # module-managed messages when installed
-    └── app/              # app-owned product messages and overrides
-```
-
-Each locale definition has this shape:
-
-```json
-{
-  "code": "pt-BR",
-  "name": "Português (Brasil)",
-  "direction": "ltr",
-  "enabled": false
-}
-```
-
-`code` must be a canonical BCP 47 tag and must match the filename. `direction` is `ltr` or `rtl`. Newly added locales stay inactive until explicitly activated.
-
-## Catalog Composition
-
-Catalogs are nested JSON objects with strings at their leaves:
-
-```json
-{
-  "common": {
-    "save": "Save",
-    "welcome": "Welcome, {name}"
-  }
-}
-```
-
-The runtime lazily loads every `catalogs/*/<locale>.json` file. Module catalogs are merged first in stable name order; the `app` catalog is merged last, so the consuming app may intentionally override module copy without modifying managed files.
-
-English defines the complete key and value-type contract. Other locales may omit keys, but translated values must retain the English type and all `{placeholder}` names. JSON objects and arrays are supported; executable expressions are not.
-
-## Development Reloading
-
-Catalog imports use Vite's `import.meta.glob`. Changes to an existing JSON dependency participate in Vite HMR and must appear without restarting the development container. A new file changes the glob membership and may cause Vite to reload the page automatically. If neither occurs, confirm that the app source directory, including `apps/web/src`, is mounted or synced by the development compose configuration.

package/dist/templates/todo/dot-claude/skills/podokit-deploy/SKILL.md

@@ -1,8 +0,0 @@
----
-name: podokit-deploy
-description: Plan, inspect, apply, verify, and roll back PodoKit releases with an explicit profile and confirmation hash, on Kubernetes or Docker Compose. Use for release, rollout, and rollback work in a generated PodoKit project.
----
-
-# PodoKit deployment
-
-Read and follow the canonical skill at `../../../.agents/skills/podokit-deploy/SKILL.md`.

package/dist/templates/todo/dot-claude/skills/podokit-deploy-fast/SKILL.md

@@ -1,8 +0,0 @@
----
-name: podokit-deploy-fast
-description: Push locally built artifacts into a running Docker Compose deployment and restart it, without building or publishing an image. Use when iterating on code against a deployed environment and a full release round trip is too slow. Not for releases, migrations, dependency changes, or anything going to real users.
----
-
-# PodoKit fast deployment sync
-
-Read and follow the canonical skill at `../../../.agents/skills/podokit-deploy-fast/SKILL.md`.

package/dist/templates/todo/dot-claude/skills/podokit-nest-endpoint/SKILL.md

@@ -1,23 +0,0 @@
----
-name: podokit-nest-endpoint
-description: Use when adding or changing a NestJS REST endpoint in apps/api — a controller/service with DTO validation, the standard error envelope, and a test. Follow this for any new backend route in a PodoKit project.
----
-
-# Add a NestJS endpoint (PodoKit conventions)
-
-1. **Module**: create/extend a Nest module under `apps/api/src/<feature>/`
-   (`<feature>.module.ts`, `.controller.ts`, `.service.ts`, `dto/`). Register the
-   module in `apps/api/src/app.module.ts` — add it **inside** the
-   `// podokit:begin:module-imports … end` fence, never outside it.
-2. **DTOs**: validate every input with `class-validator` decorators on a DTO
-   class. No `any`; give explicit return types.
-3. **Errors**: throw `AppException("STABLE_CODE", "message", statusCode)` (from
-   `@podosoft/podokit-contracts` / the app's `common/`). The global filter renders
-   it as `{ success: false, error: { code, message, statusCode, path, timestamp } }`.
-   Pick a stable, UPPER_SNAKE `code` — the frontend branches on it.
-4. **Auth**: if the `auth` module is installed the API is secure by default; mark
-   public routes with `@Public()` and read the user with `@Session()`.
-5. **Swagger**: annotate with `@ApiTags` so it shows under `/api-docs`.
-6. **Test**: add an e2e/unit test under `apps/api` or the `tests/` workspace
-   (Nest e2e or Vitest + supertest). Verify with
-   `npm run build -w {{projectName}}-api` and the test.

package/dist/templates/todo/dot-claude/skills/podokit-update/SKILL.md

@@ -1,26 +0,0 @@
----
-name: podokit-update
-description: Use when the user wants to update the project to a newer PodoKit version, pull in template/module improvements, check what they've changed vs the generated code, or take ownership of a managed file. Covers podo status/diff/doctor/update/eject.
----
-
-# Keep a PodoKit project up to date
-
-The project records how it was assembled in `.podokit/` so the toolkit can update
-its own files while keeping the user's changes.
-
-```bash
-podo status          # version, modules, file tiers, and how many managed files were edited
-podo diff            # list the PodoKit-managed files you've edited (owned files ignored)
-podo doctor          # check framework versions vs. the supported ranges
-podo update          # dry-run: preview what a newer version would change (writes nothing)
-podo update --apply  # apply it — clean updates are written; your edits are 3-way merged
-podo eject <path>    # take ownership of a managed file so update skips it
-```
-
-Rules to respect:
-- **owned** files (routes, your components, `AGENTS.md`, shadcn `ui/**`) are never
-  touched by `update`.
-- **assembled** files are recomputed from the module set — keep edits **outside**
-  the `// podokit:begin…end` fences.
-- Run `podo update` (dry-run) first and read the plan before `--apply`. Commit or
-  stash your work beforehand so a merge is easy to review.

package/dist/templates/todo/dot-cursor/rules/podokit.mdc

@@ -1,11 +0,0 @@
----
-description: PodoKit project conventions (stack, commands, code style, tooling)
-alwaysApply: true
----
-
-The conventions for this project are documented in [`AGENTS.md`](../../AGENTS.md)
-at the repository root. Follow them: web runs on :5001 and api on :5002; use
-shadcn-svelte components and the shared `DataTable`/`TableToolbar` for lists;
-Svelte 5 runes only; branch on the error `code`, not the message; keep strings in
-i18n; and respect the `.podokit/` file-ownership tiers (never hand-edit
-`// podokit:` fenced regions or `src/lib/components/ui/**`).

package/dist/templates/todo/dot-dockerignore

@@ -1,15 +0,0 @@
-node_modules
-**/node_modules
-dist
-**/dist
-.svelte-kit
-**/.svelte-kit
-.git
-*.log
-
-# Real environment files never enter a build context. The build stages copy the
-# whole repository, so an .env left here is baked into an image layer even when the
-# runtime stage does not copy it -- and getting-started tells you to create one.
-.env
-.env.*
-!.env.example

package/dist/templates/todo/dot-env.docker

@@ -1,26 +0,0 @@
-NODE_ENV=development
-PORT=5002
-POSTGRES_HOST=postgres
-POSTGRES_PORT=5432
-POSTGRES_USER=podokit
-POSTGRES_PASSWORD=podokit
-POSTGRES_DB=podokit
-BACKEND_INTERNAL_URL=http://api:5002
-CORS_ORIGIN=http://{{projectName}}.localhost,http://localhost
-REDIS_HOST=redis
-REDIS_PORT=6379
-BETTER_AUTH_SECRET=change-me-in-container-min-32-characters
-BETTER_AUTH_URL=http://{{projectName}}.localhost
-ADMIN_EMAILS=admin@example.com
-AUDIT_LOG_ENABLED=true
-RATE_LIMIT_TTL=60
-RATE_LIMIT_MAX=100
-API_KEYS=dev-key-please-change
-LOG_LEVEL=info
-STORAGE_PROVIDER=minio
-S3_ENDPOINT=http://minio:9000
-S3_REGION=us-east-1
-S3_BUCKET=podokit
-S3_ACCESS_KEY_ID=podokit
-S3_SECRET_ACCESS_KEY=podokitsecret
-S3_FORCE_PATH_STYLE=true

package/dist/templates/todo/dot-env.example

@@ -1,34 +0,0 @@
-# Copy to .env and adjust. Never commit real secrets.
-
-# ── Required (runtime) ───────────────────────────────────────────────
-NODE_ENV=development
-PORT=5002
-
-POSTGRES_HOST=localhost
-POSTGRES_PORT=5432
-POSTGRES_USER=podokit
-POSTGRES_PASSWORD=podokit
-POSTGRES_DB=podokit
-
-# Web -> API boundary (server-side only; not exposed to the browser)
-BACKEND_INTERNAL_URL=http://localhost:5002
-
-# Exact paths the web server may proxy as WebSocket upgrades to the API, comma
-# separated. Empty means none: a SvelteKit route cannot answer an upgrade, so a
-# WebSocket gateway on the API is unreachable until it is named here. Each path is
-# matched whole and must be authorised by the API at handshake time -- a relay that
-# forwards anything is an open tunnel to every private route.
-WS_PROXY_PATHS=
-CORS_ORIGIN=http://localhost:5001
-
-# ── Optional / development ───────────────────────────────────────────
-# Redis — only needed by cache/queue modules. Start it with:
-# docker compose --profile cache up
-REDIS_HOST=localhost
-REDIS_PORT=6379
-# REDIS_URL takes precedence over the individual settings below.
-# REDIS_URL=rediss://user:password@cache.example.com:6380/0
-REDIS_DB=0
-# REDIS_USERNAME=
-# REDIS_PASSWORD=
-REDIS_TLS=false

package/dist/templates/todo/dot-github/copilot-instructions.md

@@ -1,6 +0,0 @@
-# Copilot instructions
-
-This project's coding conventions for AI agents live in [`AGENTS.md`](../AGENTS.md).
-Read it before making changes — it covers the stack, commands (web :5001 / api
-:5002), TypeScript/Svelte 5/shadcn-svelte rules, the error-code envelope, and the
-`podo` tooling.

package/dist/templates/todo/dot-gitignore

@@ -1,23 +0,0 @@
-node_modules/
-dist/
-build/
-.svelte-kit/
-.env
-.env.*
-!.env.example
-.DS_Store
-*.log
-
-# e2e test artifacts
-tests/playwright/
-tests/playwright-report/
-tests/test-results/
-playwright/.auth/
-playwright-report/
-test-results/
-
-# local performance reports
-output/lighthouse/
-
-# podo dev generated compose overlay
-.podokit/runtime/

package/dist/templates/todo/dot-mcp.json

@@ -1,8 +0,0 @@
-{
-  "mcpServers": {
-    "podokit": {
-      "command": "npx",
-      "args": ["-y", "@podosoft/podokit-mcp"]
-    }
-  }
-}

package/dist/templates/todo/dot-podokit/dev.json

@@ -1,4 +0,0 @@
-{
-  "schemaVersion": 1,
-  "hostname": "{{projectName}}.localhost"
-}