SDTK-OPS

Public operations discipline for deploy, verify, and respond

SDTK-OPS is the public downstream operations product in the suite. It keeps a small truthful CLI baseline, then routes operators into skill-driven journeys for deployment, incident response, monitoring, and backup or recovery with ops-verify as the closeout skill.

Public npmSkill-driven journeysClaude + CodexWorkflow Docker validated

> DEPLOY, SMOKE, SIGN OFF — IN ONE FLOW

One bounded journey from PR-merged to release-signed-off, with real Docker proof.

SDTK-OPS isn't trying to be Kubernetes. It is trying to be the disciplined deploy + smoke + sign-off loop solo founders actually need — running locally on Docker, consuming the OPS_HANDOFF emitted by SDTK-CODE, and producing evidence QA can use to close the release.

Step 1ops-discover
Reads OPS_HANDOFF.json from SDTK-CODE. Maps the runtime surface, containers, env contract.
ops-discover report — what you're actually deploying.
Step 2ops-container
Validates Docker setup, env files, port bindings, volumes before any deploy attempt.
Container preflight log + .env.docker.local check.
Step 3ops-deploy
Runs the bounded deploy: docker compose up with explicit project name + env file.
Stack-up log, container health, end-to-end smoke trace.
Step 4ops-verify
Closeout skill: UI → API → DB smoke test, persistence check, cleanup proof.
OPS verification report — release sign-off ready for QA.

The handoff contract

SDTK-CODE produces docs/dev/OPS_HANDOFF_<FEATURE>.json at ship. SDTK-OPS consumes it on ops-discover. No copy-paste between chat windows. The deployment surface knows exactly what to deploy.

When a solo founder reaches for this

Sunday night. Feature is built, tests pass, PR is merged. You want to ship — but a vague 'deploy to prod' is what causes Monday-morning outages. ops-discover reads OPS_HANDOFF, ops-container validates env + ports, ops-deploy brings up the stack with a known compose project, ops-verify smokes UI → API → DB and proves persistence. By 22:00 you have a signed release, not a 'I think it's up' guess.

Product truth

What this toolkit does today

These cards summarize the current shipped or internal surface exactly as it exists in the local source tree.

Public package model

SDTK-OPS is carried as the public sdtk-ops-kit package. Install it with npm install -g sdtk-ops-kit before the bounded sdtk-ops CLI and skill-driven journeys take over.

Small CLI, broad skill surface

The supported CLI stays deliberately narrow: help, init, update, and runtime install/status/uninstall. Operators then work through ops-* skills rather than a large command suite.

Real local Docker proof

The current local source already proved a bounded Step-7 local Docker validation on Workflow_20260323, including backend, frontend, PostgreSQL, UI smoke, persistence, and cleanup evidence.

Current command and workflow surface

CLI baseline

sdtk-ops help

sdtk-ops init

sdtk-ops update

sdtk-ops runtime install

sdtk-ops runtime status

sdtk-ops runtime uninstall

Canonical journeys

deployment: ops-discover -> ops-container -> ops-deploy -> ops-verify

incident: ops-discover -> ops-incident -> ops-debug -> ops-verify

monitoring: ops-discover -> ops-monitor -> ops-verify

backup or recovery: ops-discover -> ops-backup -> ops-verify

Current truth

ops-discover is a skill, not a CLI command

generate remains unsupported

ops-verify closes every canonical journey in the current wave

Runtime support

Runtime	Project	User	Notes
Claude	Yes	Yes	Default scope is project; installs ops-* skills for local operational journeys.
Codex	Yes	Yes	Default scope is user; project-local installs require the explicit local CODEX_HOME=<project>/.codex contract.

Validated truth

Plan A baseline, narrowed Plan B routing, Plan C internal release hardening, and the public npm correction release are already complete in local source.
The public npm package is live, and the current help surface no longer carries internal-only wording.
Step-7 local Docker validation proved the Workflow pilot on postgres, backend, and frontend containers with end-to-end UI -> API -> DB -> list refresh evidence.
The corrected Step-7 rerun used docker compose --env-file .env.docker.local -p workflow-step7 end-to-end.
Cleanup proof showed stack down, volume removed, and .env.docker.local deleted after successful evidence capture.

Boundaries and honest limits

The public package keeps a narrow truthful CLI baseline instead of exposing deploy, incident, monitor, or recover as first-class CLI commands.
generate remains unsupported in the public package.
Provider-specific packs, Kubernetes, cloud deployment, and production topology remain outside the bounded validated surface.
Current external proof is local Docker validation on one real Workflow target, not a generic claim for every environment.
`runtime uninstall` removes only SDTK-OPS-managed skill folders for the selected runtime and scope; `npm uninstall -g sdtk-ops-kit` removes the package only.

Source-of-truth docs

Canonical usage guide

products/sdtk-ops/governance/SDTKOPS_TOOLKIT_USAGE_GUIDE.md

Step-by-step installation, runtime setup, journey selection, troubleshooting, and quick reference for the current public toolkit line.

Package landing page

products/sdtk-ops/distribution/sdtk-ops-kit/README.md

Public package truth for sdtk-ops-kit, including install, runtime support, the bounded Codex project-local contract, and the current baseline commands.

Boundary doc

products/sdtk-ops/toolkit/SDTKOPS_TOOLKIT.md

Public product boundary, current routing story, and documentation map for the SDTK-OPS surface.

Local deploy proof

governance/ai/reviews/SDTK-OPS/SDTKOPS_WORKFLOW_PROJECT_STEP7_LOCAL_DOCKER_VALIDATION_REPORT_20260324.md

Execution report for the bounded Workflow local Docker validation that currently proves the deploy path.

Position in the SDTK control plane

Where SDTK-OPS sits in the chain

SDTK-OPS is the DEV operationalization pack. It consumes OPS_HANDOFF from CODE and produces deploy + smoke + monitoring evidence that QA uses for release sign-off.

Orch—
PM—
BA—
ARCH—
DEVuses
QAuses

Highlighted owners actively use SDTK-OPS as their execution pack.

Family links

Move across the SDTK suite without losing context

These product pages map the current suite boundaries so users can move from specification to coding to operations deliberately.

Upstream