Seshat-BI: Skill for Claude Code

retail-build-warehouse

Turns an APPROVED mappings/<table>/source-map.yaml into the two migration .sql files -- silver (typed/cleaned flat table) then gold (Kimball star) -- in the order the medallion playbook proves load-bearing. It fills the silver/gold [SEAM] the retail-orchestrate conductor parks at.

The agent is the runtime: this is a procedure you follow, authoring SQL by adapting the proven warehouse/migrations/0003/0004 shape. There is NO codegen engine, NO .sql.tmpl template, and NO retail build CLI -- by design (the source-map cannot carry the transform logic; an engine would emit only boilerplate). That is a recorded design decision, not an omission to be fixed.

Author vs execute (read first)

• You AUTHOR .sql files. That is in-scope -- writing reviewable migration text, no side effects, the same category as source-mapping authoring mappings/.
• You NEVER execute. Do not open a DB connection, do not run the migration, do not run the Phase-5 PK dry-run or the Phase-6 orphan/reconcile checks -- those need live data and are the deferred DB-write seam (creds + the db extra, Principle VIII). Authoring -> static seshat check -> a HUMAN applies the SQL -> only then retail-validate. Never claim the silver/gold tables exist or were validated.

Preconditions (STOP unless all hold)

1. Canonical gate signal: mappings/<table>/readiness-status.yaml -> stages.mapping_ready.status == pass WITH a matching approvals[] entry (RS1). Its human-readable mirror mappings/<table>/unresolved-questions.md Gate status: CLEARED (ZERO open rows) MUST agree. A missing readiness-status file, mapping_ready != pass, or a mismatch between the two -> STOP (Principle IV). Never self-grant.
2. mappings/<table>/source-map.yaml parses and carries grain, primary_key, per column type/rename/drop/pii/gold_placement, the gold_star, derived_columns.
3. Read assumptions.md (the business literals the YAML cannot hold: junk-filter list, CASE maps, is_return value set, sentinels, mojibake range) and source-profile.md (row counts to annotate, the date span for the calendar).
4. Pick the next contiguous migration number NNNN over warehouse/migrations/ (S4a).
5. Adapter checkpoint -- surface the choice before writing SQL by hand. Run seshat orchestration-assess and REPORT its verdict to the human before authoring migrations. This repo ships two transformation/orchestration adapters (dbt, Dagster); hand-written migrations are the default path, so without this step they get bypassed silently rather than declined on purpose (issue #489). The assessor is read-only: it emits a categorical verdict (consider / not_recommended / already_adopted), never a numeric score, and it never adopts anything. If it says already_adopted, prefer the adapter over new hand-written SQL. If it says consider, state that and let the human choose -- do NOT adopt an adapter on your own, and do NOT treat consider as permission to skip authoring. If it says not_recommended, proceed here and say so.