The kickoff prompt

What this is. Owly Post Cloud was built in five phases against SPEC.md, each phase opened with a written brief and closed with a phase report. This is the brief for the one change that fell outside that sequence: reversing how the cloud consumes the open source core, after the original approach turned out to be the wrong trade. It is reproduced here because it shows the shape of every brief used on this project — requirements first, a hard stop where a human decision is needed, gates that cannot be skipped, and an explicit definition of success. Machine-specific setup, credentials and account details have been removed for publication.

Context

You are executing one well defined change on an otherwise finished build: how the cloud consumes the open source core. Phases 0 through 4 of SPEC.md are complete (see the phase reports and DECISIONS_LOG.md), every automated gate is green, and launch waits on a checklist of account-level actions only the owner can perform.

The original Phase 0 restructured the public core repo into a pnpm workspace with a publishable packages/core, so the cloud could consume it as a package. That was the wrong call, and it is being undone: the open source project does not get reshaped to serve a paid product built on top of it. The owner has already returned the core repo to its published state by hand. This session implements the replacement end to end, and every change of this session lands in owlypost-cloud only.

First, read SPEC.md in full, then DECISIONS_LOG.md and the Phase 0 report. SPEC.md remains the source of truth; where any older document contradicts it, SPEC.md wins.

Prerequisites (stop and ask if these are missing): both checkouts present with clean working trees, cloud gates currently green, a local database stack available for the leakage test, and the owner reachable at the stop point. No package registry, hosting, payment or mail provider account actions in this session.

Owner requirements

These override any older text in either repo:

1. No changes in the core, none. The core is an independent open source project, so this migration makes zero commits in owlypost. If anything in the core blocks the migration, stop and report; a core change is the maintainer's decision, never yours. Note in particular that the injectable fetcher and the summarization worker pool introduced during the build were core changes made for the cloud's benefit — they are gone, and you do not reintroduce them, even though the cloud would profit.
2. Core changes must roll out to the cloud. A new commit on core main reaches production as one submodule bump PR that passes all gates.
3. The core is the basis of the cloud. No fork, no copies, no reimplemented core logic in the shell.

The migration: three steps, one hard stop

Step 1 — Verify the core — read-only, zero commits

The owner already removed the publish machinery from the core by hand. This step verifies; it never fixes. Do not write anything to the core repo.

• Confirm what the cloud actually has to consume: the flat lib/ surface (pipeline functions, the Storage interface, feed detection) as it exists on main.
• Grep for leftover publish machinery: publish workflow, publishConfig, files, prepack, build-only tsconfig, a publish dry-run step in CI. Expected result: none. List any leftovers, and any lingering registry references in the core docs, in the report for the owner; change nothing yourself.
• Run the core repo's own gates (lint, typecheck, test, build) to confirm the repo is healthy exactly as she left it. If a gate script itself no longer exists, note it rather than restoring it.
• Compatibility proof: with the cloud's existing dependency still in place, run the cloud's full gate against this exact core state. If anything fails, stop and report; the core is hers to change or not.

Stop — the owner publishes

Report the verification results, then stop. She pushes both repos herself. When she gives the go, read the main commit sha from the remote (or ask her for it). Never push to a remote yourself.

Step 2 — Wire the submodule (cloud repo)

• Add the public core repo as the vendor/owlypost submodule, checked out at the commit she published, and commit the gitlink. The .gitmodules URL must be the public https URL so that CI and the host clone it without credentials.
• Make the repo a pnpm workspace, replace the old dependency with a workspace:* dependency on the cloud-owned bridge package, and run a fresh install.
• Verify the build still transpiles the core's TypeScript source (consumption is source directly, unchanged from before).
• CI: check out with submodules; delete the sibling-checkout steps and every deploy-key reference. A public repo needs no key.
• Enable the Renovate git-submodules manager, so core upgrades arrive as one PR.
• Run all gates: lint (including the core-table gate), typecheck, unit tests, the cross-tenant leakage test, and the production build. This is the first real validation of the consumption model; skip nothing.
• Prove the upgrade path once: move the submodule to another reachable commit, run typecheck to show a bump exercises the gates, and move it back to the pin.

Step 3 — Make the documentation true

• Commit the updated SPEC.md, CLAUDE.md and launch checklist, replacing the old versions. Verify the checklist against what you actually built; if reality differs, adjust the checklist and log why.
• Rewrite the "Upgrade the core" section of the runbook to the submodule bump flow.
• Append the implementation entry to DECISIONS_LOG.md, noting that the core cleanup itself was done by the owner by hand, outside any session.
• Update the open items in PHASE_REPORT_4.md: the publishing plan and the earlier git dependency pin are gone.
• Run the full gate once more, then write a migration report: what changed in each repo, evidence, deviations. Stop. The launch checklist stays with the owner.

Ground rules (unchanged from the build)

1. Audit before you build; never trust documentation claims about code state.
2. Deviations: when documents are silent or reality contradicts them, pick the smallest solution consistent with SPEC §1, record it in DECISIONS_LOG.md, and flag it in the report. Do not stall; do not silently improvise.
3. Quality gates are non-negotiable: TypeScript strict, no any; core-table access only through the tenant-scoped adapter (grep gate); the leakage test stays green; no hardcoded quota numbers; secrets only via env config; payments stay in test mode.
4. Respect the stop point, and never push to any remote yourself.

Definition of success for this session

The cloud builds and passes every gate with the core consumed exclusively through the pinned vendor/owlypost submodule, and the core repo received zero commits from this session. No publish machinery exists in either repo. A submodule bump is demonstrated and documented as the upgrade path. SPEC.md, CLAUDE.md, the runbook and the launch checklist describe this reality and nothing else.

Begin with the audit of both repos, then step 1.