TinyStudio managed service

TinyStudio is a human-reviewed delivery system for one narrow offer:

The Website Correction

The buyer is a founder-led Managed IT/MSP/cybersecurity company with a live site and a high-value offer. The first 3 clients are exactly $1,000 founder pilots. Each sprint fixes one highest-leverage page and leaves the client with a usable, measurable implementation package.

Included in every paid sprint:

• fault map for the selected page
• rewrite or redesign of that page
• one implementation pass or a dev-ready handoff
• search-trust basics (titles, headings, internal links, FAQs, proof, and crawl essentials)
• before/after proof
• a Loom walkthrough
• a measurement plan
• one revision
• 14-day implementation tracking

Day 0 starts only after payment, required context, an approval owner, and an implementation owner are present. Client delay pauses the clock. The sprint does not guarantee revenue, rankings, ROAS, conversion, booked calls, or sales volume.

Human review gates fit, claims, client-facing work, delivery/acceptance, and renewal. Automation may prepare research, drafts, QA, packages, and routing. It may not autonomously send, publish, spend, approve, accept, or renew. Operational dates deliberately use Asia/Kolkata regardless of host or CI timezone; its fixed +05:30 offset has no daylight-saving transition.

• PRODUCT.md and MEMORY.md hold the current product truth.
• growth-brain/offer.md is the canonical offer.
• growth-brain/sales/ contains the one-page offer, proposal, and buyer-room templates.
• growth-brain/sprint-checklist.md, growth-brain/delivery-template.md, and growth-brain/workflows/client-sprint-workflow.md define delivery.
• growth-brain/quality/ contains acceptance and proof gates.
• growth-brain/ops/agency-config.json is the shared configuration for generated drafts.
• src/check-product-truth.mjs checks active service surfaces only.
• public/ is the separate tinystudio.in portfolio and is intentionally outside the service truth gate.

1. Confirm fit and the one highest-leverage page.
2. Collect payment, required context, approval owner, and implementation owner.
3. Start Day 0; pause the clock when the client is blocking progress.
4. Prepare research and drafts, then complete every human review gate.
5. Deliver the approved page rewrite or redesign, implementation pass or handoff, proof, Loom, measurement plan, revision, and 14-day tracking.
6. Review delivery and acceptance with the client, then separately review renewal.

The operator engine turns that loop into an offline queue. service:queue prepares bounded work packets; service:decide is the only review-decision writer; service:day0 promotes a paid founder pilot into the canonical client scaffold; service:resume maintains the clock; and service:evidence records outcome, implementation or handoff, before/after proof, Loom, baseline, acceptance, usefulness, and tracking. Missing context becomes a human-reviewed needs-info request. Work must stay on the reviewed page and preserve the accepted metric and baseline. client:new is repair-only, while requests beyond the included revision stop at scope-review until a reviewer authorizes scope and fee. Changed inputs, partial work, cross-page work, unbound claims, stale decisions, replays, and missing evidence fail closed. Client-facing work requires a fresh decision bound to its artifact hash and exact no-guarantee policy. Interrupted state changes leave roll-forward records that service:repair -- APPLICATION_ID can complete exactly.

clients/, prospects/, service-decisions/, and runs/service-engine/outputs/ contain private, load-bearing records and are intentionally git-ignored. After every mutating service command and before any cleanup, create a permission-restricted snapshot at an explicit path outside this repository:

npm run service:backup -- --output "/absolute/private/outside-repo/tinystudio-service-YYYYMMDD-HHMMSS"
npm run service:backup-check -- --input "/absolute/private/outside-repo/tinystudio-service-YYYYMMDD-HHMMSS"

The export takes the shared service lock and rejects pending promotions, symlinks, special files, in-repo or existing destinations, unsafe permissions, and changed bytes. Restore only into a clean clone: verify the snapshot; copy clients/, prospects/, service-decisions/, and runs/service-engine/outputs/ to the same relative paths without merging or overwriting; run npm run service:queue -- --mode=prepare --scope all; then run npm run service:queue-check -- --scope all. Keep the snapshot local until a human approves its storage destination, access, retention, and deletion policy.

The Friday retention-prep automation is optional only while there are no client records. Once a client exists, retention:automation-check fails closed and prints the exact replacement prompt. Independently of client records, the check refuses to pass on a checkout that is behind remote main (remote refs/heads/main must be an ancestor of the local HEAD, proven by bounded ls-remote/fetch), on a canonical retention workspace that is itself behind remote main (the Friday loop would run its old gate code), or on an isolated empty checkout whose canonical state roots (clients/, prospects/) do not exist as real directories in the repository's main worktree. A missing automation file is itself a failure even at zero clients — the scheduled loop is required before the first client becomes active, so an aligned-but-empty workspace without the guard must not green-pass. The canonical workspace is the git main worktree — the entry of git worktree list whose git-dir equals the repository's common git dir — never a twin worktree that merely happens to hold the refs/heads/main branch while the main worktree is detached, and never whichever worktree happens to head the porcelain list. The replacement prompt printed as replacementPrompt requires the Friday agent, before inspecting any private state, to fetch origin/main, get the named workspace onto origin/main, re-run the freshness proof, and refuse service inspection if the named workspace is still behind or diverged; the gate's proveFreshness proof stays remote-main ancestry, not exact-SHA equality.

The same gate runs inside the shared npm run check / npm test suite in advisory mode (--advisory, also available as npm run retention:automation-check:advisory): findings stay visible in the report, but they demote the status to warn and exit 0 instead of failing the run. This keeps machine-local private state (unrecorded decisions, missing engine artifacts, a stale canonical workspace) from permanently reddening the portable regression suite and starving every check after it; the strict fail-closed behavior above remains the default for the Friday retention loop itself.

Run the checks before treating a packet as ready:

npm run product:truth
npm run claims:check
npm run config:check
node test/test-service-engine.mjs
node test/test-cross-repo-service.mjs --public-repo "/absolute/path/to/TinyStudio.io"
git diff --check

Same-fix PR pairs kept appearing because the same finding gets dispatched to multiple lanes (fix/operator-export-cli-help #36 and fix/operator-export-cli-help-lane1 #44 were byte-identical patches; #39/#49 and #40/#52 followed the same pattern). The in-repo duplicate guard was deleted in #303: the agent-dispatch queue, GitHub rulesets and auto-merge now own same-fix dedup, so there is no local command to run. docs/no-glue-kept-scripts.md records why.

TinyStudio does not become SaaS by assumption. Graduation requires at least 10 paid sprints, the same problem in at least 7, at least 70% workflow repeatability, usefulness at least 8/10, approval at least 70%, a recurring need, and at least 3 deposits or preorders. Until every threshold is evidenced, this remains a managed service.

• Never broaden the active buyer, page scope, or deliverables without a reviewed decision.
• Never make revenue, ranking, ROAS, conversion, booked-call, or sales-volume guarantees.
• Never send, publish, spend, approve, accept, or renew without the applicable human gate.
• Keep the tinystudio.in portfolio in public/; it is not service positioning.