This was the first real sub-agent fanout: Epicurus took Content Studio persistence, Erdos built the Weekly Commitments coaching loop, and Plato tightened the HGO episode-page publish handoff. The work merged through PR #23 and shipped to both Studio and Web after Cloud SQL schema sync jobs completed.

The new pieces are still intentionally controlled: Content Studio project saves are manual, Weekly Commitments require a client-visible grant, and the HGO handoff packet stops before any public publish action. That keeps the system useful now without pretending review and publishing are automatic.

Added a client-specific coaching tool catalog and manual grants so Homer can enable prep, reflection, accountability, resources, milestones, and check-ins without changing subscription tiers.

Added a private Growth research library for memberships, owned checkout, podcast subscriptions, video monetization, ads, book affiliates, direct sponsors, merch, SEO loops, and disclosure rules.

Added the internal Growth desk for SEO briefs, analytics snapshots, ad and affiliate placement planning, plus gated GA and AdSense runtime hooks.

The integration page is no longer only a readiness board. It now has a provider event inbox for verified webhook deliveries and a calendar sync lane that records every attempt as an app-owned job.

This moves billing, supporter, scheduling, and merch infrastructure closer to production while keeping the risky parts separated: no card handling, no automatic entitlement changes, no merch fulfillment, and no checkout creation until the offer path is ready.

This is the business-infra foundation for the next wave. WorldHub can initialize provider connection rows, check which environment names are configured, and show the operational ledger we will use for billing, supporter memberships, calendar sync, and merch fulfillment.

It still does not store secret values or call providers. That keeps the next provider adapters reversible: Google Calendar can write sync jobs, Stripe and Patreon can land webhook events, and merch can move through app-owned orders and fulfillment jobs.

This is the first careful step past our old no-database-write boundary for the HGO publishing flow. A team operator can open a ready staged artifact, review the proposed episode route and generated draft packet, then save one private publish-intent row for follow-up.

The important part is what it still does not do: no public route is created, no MDX file is written into published content, no provider is called, and /episodes is untouched. We now have a durable checkpoint for future publishing instead of another copy-and-paste handoff.

This makes the episode-page pipeline more portable: a packet can move through chat, file download, or another agent handoff and still be checked before anyone touches public content.

The lab rejects packets that claim public state or write/publish/provider side effects, keeping the next publishing step honest.

This keeps episode-page publishing moving toward a real draft workflow while staying inside the private review boundary: no public route is created, no content file is written, and no provider is called.

The operator can still download the full publish-draft packet, but now the actual proposed MDX and frontmatter are one click away for review, sharing, or a future publish step.

This is the next step between staging and publishing. The review detail page can now export a draft packet with proposed frontmatter, a private MDX body, file targets, review state, and safety flags.

The new preview route renders the saved artifact through the same HGO projection renderer used by staged and synthetic pages. It stays behind team auth and does not write content files, publish /episodes, mutate the stored artifact, call providers, or certify public-safety review.

This turns the queue from a list into a working review station. A team operator can see why an artifact is or is not ready, copy the immutable artifact, copy the publish-candidate packet, and export a review brief for the next agent or human pass.

The boundary is still deliberate: the detail page does not create public routes, write content files, publish pages, mutate the staged artifact, call providers, or certify public-safety review.

The Studio handoff still keeps publishing manual and reviewed: it opens HGO staged import, links to the private publish queue, and does not call providers or create public pages.

The queue is still deliberately private planning space. It does not create public episode routes, publish pages, certify public-safety review, or call providers, but it gives the team one focused surface for deciding what is ready for human publish review.

This turns the private HGO artifact shelf into a working handoff station instead of a passive list. A team operator can copy the immutable artifact JSON, download it, open the artifact inspector with the JSON already on the clipboard, or copy/download the derived episode-page publish-candidate packet.

The boundary stays intact: these controls do not publish, approve, mutate the stored artifact, create /episodes routes, call providers, or certify public safety. They just make review and agent handoff faster.

This tightens the podcast and episode-page handoff. The operator can build a production packet in Content Studio, use Copy + Open HGO Import, then load the copied JSON into the HGO staged review route without hunting through downloads or chat snippets.

The HGO import route now says the true thing: browser review happens first, signed-in team members can explicitly save a private review artifact, and nothing in this path publishes or replaces /episodes.

The production packet already carried the useful podcast, book, and episode-page handoff data. This slice makes that data easier to move: copy the selected production packet, copy just the HGO projection draft when it exists, or open the HGO staged importer from the Studio panel.

This keeps the safety boundary intact. The buttons do not publish, call providers, mutate production content, or send data automatically across services; they reduce the manual work needed to pass the packet to the next private review surface.

For the top-priority workflows, this means podcast production and episode-page staging can move from Studio to HGO review with fewer little papercuts while the project still keeps explicit human review.

The new helper keeps the story data as the single source of truth while making updates cheaper: pass a title, summary, paragraphs, commit chips, links, and tags, and it prepends a valid entry.

This matters because the journal is only useful if it stays current. The script turns the team-facing story into a normal release habit instead of a special chore.

The helper has a focused node:test suite and a package script, so future agents can prove the entry writer still behaves before they trust it on the live story file.

The progress thread already existed as an internal team route. This slice turns it into a public-facing build journal without creating a second source of truth: /team/progress and /updates now render the same story data through one shared view.

The page is meant to read like short field notes from the build, not like raw git output. Each entry can keep the useful commit, deploy, rollback, and trail links while still explaining why the work matters in plain language.

This is also a coordination move. Future agents have a visible place to record meaningful commits, merges, and deploys, and the team can see momentum without needing to sit inside every terminal window.

The custom domain finished its handoff. Public DNS points app.highgroundodyssey.com to ghs.googlehosted.com, Cloud Run's managed certificate is provisioned, and the Google OAuth client accepts the app-domain callback URI.

Cloud Run now runs the web service with AUTH_URL and HGO_SITE_URL set to https://app.highgroundodyssey.com. The traffic split was moved to revision web-00040-zjr after the env update created the new revision but left traffic pinned to web-00039-9nw.

The smoke checks passed: the app-domain health endpoint returns 200, protected team routes redirect to sign-in, and the generated Google sign-in form sends users to Google with redirect_uri=https://app.highgroundodyssey.com/api/auth/callback/google. Rollback stays simple: route traffic back to web-00039-9nw.

The previous HGO slice let us save staged artifacts and move them through private review. This one makes the next step concrete: when an artifact is marked as a staging candidate, the team page can show the proposed `/episodes/...` route and a structured handoff packet.

The packet is deliberately not a publish button. It creates no route files, mutates no database rows, calls no providers, and does not certify public safety. It is the checklist and JSON handoff that tells the next agent or human what still has to be true before an episode page can go public.

This is the shape we want for fast creative work: turn review state into the next concrete artifact, keep rollback visible, and preserve the boundary between private staging and public publishing.

This was the first serious admin move toward getting High Ground Odyssey fully onto Google Cloud. The web app already ran on Cloud Run, but its runtime database secret still pointed at Neon. We staged a separate Cloud SQL database named web, a least-privilege web_app user, and a separate Secret Manager URL so the move could be tested without changing live traffic first.

The staged database got the Prisma schema through a one-off Cloud Run Job. Then a guarded Postgres copy job copied only public schema data from the old source to Cloud SQL, refusing non-empty targets and printing only row counts. The successful copy moved 20 rows: users, roles, membership plans, coaching requests, client profiles, and one appointment.

Before routing users, Cloud Run created a no-traffic revision with the Cloud SQL secret and tested health, home, HGO staged import, and team-progress redirect behavior. After that passed, live traffic moved to web-00033-den. This progress entry itself then shipped on web-00034-n4p, still mounted to the Cloud SQL secret. The previous Cloud SQL revision is the immediate rollback target, while the Neon-backed revision remains a deeper rollback anchor while the new database path gets runtime history.

Saving a staged artifact gave us a private shelf. This slice made the shelf useful: each saved packet now carries review event counts, last-reviewed metadata, and explicit private review controls.

The controls are intentionally narrow. They update review metadata and append event-log entries. They do not publish pages, create episode routes, call providers, or turn an artifact save into public approval.

The API now also supports PATCH updates for team-gated review and archive actions, so future Studio and HGO surfaces can move artifacts through the same private lifecycle.

The browser-only HGO review loop proved the packet shape first. This slice added the first private persistence layer: a team-gated API, a private team list page, and an explicit save button on the staged importer.

Saving still does not publish anything. The submitted artifact remains the browser-created review packet, while the server stores separate metadata for review status, promotion readiness, blockers, warnings, and rollback.

The schema was applied through a one-off Cloud Run Job using the web database secret, then the web service deployed to Cloud Run revision web-00019-tkx. Live checks confirmed the public import page loads, the artifact API rejects anonymous users with 401, and the team artifact page redirects to sign-in.

The previous Studio slice could generate production packets. This slice connected the other side of the handoff: HGO no longer needs the operator to manually split out the draft before review.

When a podcast or episode-page packet is pasted into `/projection-stage/import`, the importer checks the packet kind, schema version, provider-call flag, public-publishing flag, real-manuscript flag, and human-review flag. Only then does it extract `hgoProjectionDraft` and run the existing HGO projection validation and review gate.

This keeps the workflow fast without pretending the packet is published. It is still browser-only staged review, with no database write, provider call, public page promotion, or real content in tests.

The previous slice made manual server checkpoints real. This one made them practical. Inside Content Studio, the operator can refresh checkpoint history, inspect project counts and blocked/ready state, and load the exact checkpoint they want.

That matters because we are intentionally moving quickly. Browser-local state is still the fast working surface, but server checkpoints now behave like a usable recovery rail instead of a single blind save slot.

This does not introduce autosave or canonical publishing state. Checkpoints are still explicit, private Studio recovery anchors.

The board is no longer just a checklist. For the selected project, Studio now derives a production packet with delivery targets, current checklist state, safety flags, and review-required agent task prompts.

For podcast and episode-page work, the packet includes a staged HGO projection draft that validates against the existing HGO projection import contract. That means the next loop can move from Studio planning into HGO staged review without pretending anything is public-safe yet.

The guardrails are still intact. These packets do not call podcast hosts, publish pages, certify citation safety, touch provider APIs, or use real manuscript text in tests. They are handoff artifacts for review and next action.

This landed through the same merge-to-main and GitHub Actions deploy path. Studio is now serving the production-packet UI on Cloud Run.

The board is still browser-first, which keeps the fast creative workflow intact, but it no longer has to be trapped in one browser forever. A signed-in Studio user can save a manual checkpoint and later load the latest checkpoint from the server.

The checkpoint model is intentionally narrow. It stores the Content Studio workspace, a content hash, project counts, and status counts. It does not autosave, call providers, publish public pages, or move real manuscript material into tests.

This also added a repeatable database sync path. The schema change was applied through a one-off Cloud Run Job that used Studio's existing Cloud SQL connection and database secret, then the merged main commit deployed through GitHub Actions.

The live smoke checks passed after deployment: Studio health, Content Studio page, the new snapshot API's sign-in guard, web health, and the team progress route.

The Cloud Run side is already lined up: app.highgroundodyssey.com routes to the web service, and Cloud Run is waiting only for the public DNS record before it can issue the managed certificate.

The missing piece is intentionally narrow. In the DNS manager for highgroundodyssey.com, add app as a CNAME to ghs.googlehosted.com. Root and www stay untouched until we deliberately move the public site.

A new operator command, pnpm web:domain:check, now checks public DNS, the Cloud Run mapping, certificate state, and the current web origin settings. It also prints the OAuth callback and Cloud Run env update sequence so the cutover is repeatable instead of living only in chat.

After this landed on main, GitHub Actions redeployed both services. Web is serving revision web-00006-m6l and Studio is serving revision studio-00028-qlk. Health checks passed for both.

This is a good example of the operating style we want. The workflow got far enough to prove auth, checkout, dependency install, web build validation, Studio typecheck, and the app readiness suites. The blocker was not the app. It was Cloud Build's source upload path.

The fix keeps Cloud Run as the live target and keeps the deploy helpers as the shared path, but gives CI its own image-build strategy. Local operators can still use Cloud Build by default. GitHub Actions now uses direct Docker build and push so the release path depends on fewer Google Cloud moving parts.

The deployer was granted scoped write access to the existing Artifact Registry repository, not broad artifact admin. The first successful run deployed web revision web-00004-fml and Studio revision studio-00026-hpm.

The logs also exposed a useful hardening item: the slim Docker images should install OpenSSL so Prisma does not guess its runtime library target. That fix is the next small Cloud Run polish slice.

This is the beginning of the tighter release loop: merge to main, let the workflow decide which live service should move, and keep manual dispatch available when the team wants to redeploy both services on purpose.

The deployer uses GitHub OIDC instead of a downloaded service account key. It has the Cloud Build and Cloud Run permissions needed to deploy, and it can act only as the existing web and Studio runtime service accounts.

The workflow reuses the deploy helpers we already proved locally. That means each deploy still builds through Cloud Build, runs the same app-specific checks, smokes the live route, and prints rollback commands.

The important shift is operational: web is no longer just a repo build target. It now has a live Cloud Run service with the same deployment posture we proved on Studio.

The first deploy mounted the web database, auth, Google OAuth, and team-role secrets from Secret Manager, attached the existing Cloud SQL instance, and opened public HTTP access at the Cloud Run layer while keeping team routes protected by app-level auth.

The public home page and health route are reachable. The team progress page correctly redirects unauthenticated visitors to sign-in, which means the route is live without exposing the internal story.

The big move today was turning a planning conversation into a live working surface. Content Studio is still intentionally lightweight, but it gives the team a place to capture active creative projects and the steps around them instead of letting the work disappear into chat scrollback.

WorldHub came along for the ride as the business layer: offers, memberships, coaching, supporter workflows, merch, and future provider connections now have a shared vocabulary. Nothing is wired to payment or fulfillment providers yet, which is exactly right for this stage.

After validation, the integrated Studio runtime was deployed to Cloud Run from the merged main SHA. The live app and main are aligned again.

The goal is not bureaucracy. The goal is to make it easy for agents to move quickly without stepping on active work. The board names lanes, branches, file ownership, deployment posture, and rollback habits.

The progress thread is the readable record. It is terse by design: what changed, what passed, what deployed, what is blocked, and what another agent should know before editing.

A continuity note was pulled back into main after the older Content Studio terminal closed, so future sessions can recover the north star and current operating model quickly.

This slice deliberately avoids provider calls and public publishing. It proves the working pattern first: capture a real project, assign a workflow lane, track the next action, and export a handoff packet.

The important thing is that the tool starts meeting the way the work actually happens. It can grow toward real persistence, APIs, and provider integrations once the daily shape proves itself.

The board is not the final Content Management Studio. It is the first grip point.

This is the working model we want: one active media lane can keep building while the integration thread keeps main healthy and deployable.

The next connection point is obvious but should be deliberate. Studio Cut media packages should eventually flow into Content Studio podcast and video projects, with rescue paths and local-first workflows preserved.

Until then, the board treats Studio Cut as occupied space.