@veleads/gtm 0.4.0 → 0.7.0

package/CHANGELOG.md

@@ -5,6 +5,58 @@ All notable changes to `@veleads/gtm`. Each entry is tagged: **no action**, **op
 
 ## [Unreleased]
 
+## [0.7.0] - 2026-10-24
+- **opt-in** `gtm stack up | down [--wipe] | status`: each project repo runs its own stack (Postgres +
+  hatchet-lite + gtm worker) on Docker, as compose project `gtm-<project_id>` with its own volumes. The
+  worker is the image `ghcr.io/veleads/gtm-worker:<version>` matching the pinned core; it applies
+  database migrations when it starts. Connection settings go to `~/.gtm/stacks/<project_id>.env`
+  (used by `gtm job`), provider keys to `~/.gtm/stacks/<project_id>.secrets.env`; nothing is written
+  into the repo. Ports are configurable (`GTM_PG_PORT`, `GTM_HATCHET_UI_PORT`, `GTM_HATCHET_GRPC_PORT`)
+  and bound to localhost only. Releases now also publish the worker image. The gtm-core development
+  stack (`pnpm stack:up` + `pnpm worker`) still works as a fallback for `gtm job`.
+- **action** One database per project: each project repo runs its own stack (Postgres + Hatchet +
+  workers) and core holds no project state. Rows no longer carry `project_id`; unique keys are now
+  per database (`accounts` on `tam_id` + `domain`, `contacts` on `linkedin_url`, …). A new
+  single-row `project` table binds the database to one `project_id` on the first job, and workers
+  refuse jobs for any other project. The `account`, `contact`, `lead` and `signal` schemas drop
+  `project_id`; `project.yaml` and job payloads keep it. DB migration
+  `20261025000000_database_per_project` binds an existing single-project database automatically and
+  **refuses to run on a database that holds more than one project**: give each project its own
+  database (copy its rows, filtered by `project_id`) before upgrading. Point each project's
+  `DATABASE_URL` at its own database.
+
+## [0.6.0] - 2026-10-24
+- **no action** Layered ICP: `context/icp.yaml` can have an optional `core.firmographics` that every
+  segment shares; segments then hold only what differs, and a segment field **replaces** the same core
+  field (lists are not combined). Segments may restrict `personas`. Existing ICPs are unchanged and
+  stay valid. A segment that resolves to no filters at all is rejected.
+- **no action** `gtm icp` shows the ICP as jobs see it: core, each segment's final filters (marking
+  which fields the segment sets), personas and exclusions. `gtm job tam` uses the resolved filters.
+- **no action** `01-icp` skill and `icp.md` / `icp.yaml` templates rewritten around the five layers
+  (core, segments, personas, signals, exclusions) with a hypothesis, evidence and success criteria per
+  segment; `research` now outputs core and segment candidates. AGENTS.md states the assumption: from
+  stage 2 on the ICP is approved (stage 1 ends with a decision, revising later is normal).
+- **opt-in** `gtm job tam <campaign>` is available: builds the TAM through the workers (Hatchet) into
+  Postgres and prints the funnel (TAM → reachable → active), cost, run_id and a run-log row. Needs an
+  approved ICP and `config.yaml` → `tam: { source, max_accounts_per_segment }`; `mock-accounts`
+  generates fictional accounts to prove the pipeline locally. Re-runs update instead of duplicating;
+  suppression lowers "active". Local stack: `pnpm stack:up` + `pnpm worker` in gtm-core.
+
+## [0.5.0] - 2026-10-24
+- **action** Research-first intake: new `research` skill writes `context/research.md` (sourced facts,
+  public customers as suppression candidates, competitors as exclusion candidates, triggers) before any
+  questions; `00-intake` drafts intake from it and asks only what research can't answer, with an
+  example per question. `validate` warns while `context/research.md` is missing.
+- **action** GitHub-enforced approvals: when `owners.approver` is an `@handle`, ICP and copy sign-off is
+  the approver's APPROVED review on a PR. `gtm approve icp|copy … --pr <n>` verifies it on GitHub and
+  records `approved_via`; `gtm validate` requires it, and `--verify-github` (in the CI template)
+  re-checks the review and that the reviewed commit matches the pinned hash. `gtm sync` maintains a
+  CODEOWNERS block for the approver. Named approvers keep `--by`. Existing repos: copy
+  `.gtm/templates/repo/github/workflows/gtm.yml` to enable verification in CI.
+- **opt-in** `gtm track` mirrors stages and gates into a tracker (`project.yaml` → `tracker.kind`:
+  `github` issues, or `none`, the default for existing repos). New `gtm github setup [--apply]` creates
+  labels and the approval ruleset. Guide: `.gtm/guides/github.md` (incl. an org-wide board).
+
 ## [0.4.0] - 2026-10-24
 - **no action** `gtm init . --name "<Name>"` sets up the current folder instead of creating a
   subfolder (slug from the folder name, e.g. `gtm-project-acme` → `acme`, or `--slug`). Built for a

package/README.md

@@ -48,8 +48,10 @@ command writes**, and examples, without running it.
 | `new-campaign <slug>` | scaffold `campaigns/<slug>/` | that folder |
 | `validate [campaign]` | schemas, gates, cross-references, no lead data, core sync | nothing |
 | `status` | campaigns, stages, gates | nothing |
-| `approve icp --by "<name>"` | record ICP sign-off, pin its hash | `context/icp.yaml` |
-| `approve copy <campaign> --by "<name>"` | record copy sign-off, pin its hash | campaign `config.yaml` |
+| `approve icp --pr <n>` / `--by "<name>"` | record ICP sign-off (GitHub PR review, or by name), pin its hash | `context/icp.yaml` |
+| `approve copy <campaign> --pr <n>` / `--by "<name>"` | record copy sign-off the same way | campaign `config.yaml` |
+| `track stage\|gate-open\|gate-done …` | mirror stages and gates as GitHub issues (or `none`) | tracker only |
+| `github setup [--apply]` | labels + approval ruleset on the repo | GitHub settings |
 | `sync [--check]` | copy the core kit into `.gtm/` + `AGENTS.md` | `.gtm/`, `AGENTS.md` (nothing with `--check`) |
 | `migrate [--dry-run]` | move YAML files to the current schema versions | YAML files |
 | `upgrade [version]` | install a newer core, sync, migrate, validate, show changelog | deps, `.gtm/`, YAML |
@@ -57,9 +59,18 @@ command writes**, and examples, without running it.
 
 Exit codes: `0` success, `1` failure or validation errors.
 
+## GitHub mode
+
+Set `project.yaml` owners to GitHub handles (`approver: "@maria"`). ICP and copy sign-off then **is**
+the approver's PR review: `gtm sync` makes them the CODEOWNER of those files, `gtm approve … --pr <n>`
+verifies the review on GitHub, and CI (`gtm validate --verify-github`) re-checks it against the exact
+reviewed content. Stages and gates are mirrored as issues with `gtm track`. Approvers who aren't on
+GitHub (or solo projects) use a plain name and `--by`. Details: `.gtm/guides/github.md`.
+
 ## For coding agents
 
 - Inside a project repo, **read `AGENTS.md` first** and follow it; then `PROJECT.md`.
+- Intake starts with the `research` skill: research the business before asking anyone anything.
 - Read-only commands are always safe: `validate`, `status`, `sync --check`, `migrate --dry-run`,
   and any `--help`.
 - Never edit `AGENTS.md` or `.gtm/`. Never run `gtm approve` unless a named human explicitly approved