Summary: Schema PR queue is empty.


Summary:
Schema PR queue is empty.

(The reviewer script exited early due to missing database environment variables `LIFEOS_CORE_DB_USER` and `LIFEOS_CORE_DB_NAME` — no PRs were processed.)


Summary:
The reviewer script ran but exited with a fatal error: missing required environment variables `LIFEOS_CORE_DB_USER` and `LIFEOS_CORE_DB_NAME`. The script couldn't connect to the database because those credentials weren't set in the cron environment.

**What happened:** The LifeOS schema PR reviewer script launched successfully but immediately halted — it needs `LIFEOS_CORE_DB_USER` and `LIFEOS_CORE_DB_NAME` to be defined in the environment. These are likely set in a `.env` file or shell profile that the cron job isn't sourcing.

**Fix needed:** The cron command should source the relevant env file before running, something like:
```
source /Users/bigdaddy/lifeos/.env && /Users/bigdaddy/lifeos/schema-governance/run-reviewer.sh
```

Or those variables need to be added directly to the cron environment config. Mark should check where those DB credentials are stored and update the cron definition accordingly.


Summary:
**LifeOS Schema PR Rejected** — needs a quick fix before it can land.

**PR:** `add-supplement-stack-and-stack-item-tabl`
**What it does:** Adds `supplement.stack` and `supplement.stack_item` tables — the "named protocol" feature (Morning Stack, Night Stack, etc.) for tap-to-log daily supplement routines.

**Why it was rejected (3 issues):**

1. 🔴 **Blocking: rollback SQL is a placeholder** (`-- TODO: write rollback SQL`). Governance requires real rollback SQL. The fix is trivial — just `DROP TABLE IF EXISTS supplement.stack_item; DROP TABLE IF EXISTS supplement.stack;` (plus the trigger drops).

2. 🟡 **Minor: `data_loss_risk` should be `"none"` not `"low"`** — pure additive migration, nothing existing is touched. "low" unnecessarily triggers a Mark-notification + 10-min delay on apply.

3. 🟡 **Minor: `test_queries` is empty** — needs at least two basic `SELECT COUNT(*)` sanity checks.

The migration SQL itself is clean — IF NOT EXISTS guards, correct FK refs, proper triggers, good index naming. One resubmit with those three fixes and it should auto-approve.

*(Note: Discord notify failed during the run — bad token format in env. This message was delivered via main session instead.)*


Summary:
🔴 **LifeOS Schema PR Rejected** — `add-media-schema-for-content-watch-track`

The AI reviewer rejected this PR with **high confidence**. Here's the summary:

---

**PR:** Add media schema for content/watch tracking (Trakt)
**Submitted by:** markbot • **Reviewed:** 5:00 PM ET

**Hard blockers (auto-reject):**
1. **Rollback SQL is a placeholder** — `-- TODO: write rollback SQL`. Governance rule: no placeholder rollbacks. A complete rollback dropping all objects in reverse dependency order is required.
2. **data_loss_risk misreported** — declared `low` but this is a pure additive migration (new schema + new tables only). Must be `none`. Misreporting risk is a governance violation.

**SQL correctness issues:**
3. **PostgreSQL NULL semantics bug** — `UNIQUE (person_id, title_id, episode_id)` on `media.rating` doesn't enforce uniqueness when `episode_id IS NULL`. Needs two partial unique indexes instead.
4. **Missing `created_at`** on `media.sync_cursor` — required by convention.
5. **Singular table names** — all 5 tables violate the `snake_case_plural` convention. Should be: `media.titles`, `media.episodes`, `media.watch_events`, `media.ratings`, `media.sync_cursors`.
6. **`indexes_added` empty** — migration creates 7+ indexes but the manifest field is `[]`. Breaks the audit trail.

**Good news:** The core design is solid. Core.event anchoring, trakt_history_id dedup, TMDB enrichment hooks — all correct. Fix the blockers and this should approve cleanly on resubmission.

---

*Note: The Discord notify in the reviewer script failed due to a newline in the bot token header — that's a separate bug to fix.*


Cannot read properties of undefined (reading 'properties')


Summary:
A PR was processed. Here's the summary:

**LifeOS Schema PR Review — 1:30 PM ET**

- **PR:** `add-supplement-stack-and-stack-item-tabl`
- **Decision:** ✅ **Approved** (high confidence, round 1 of 2)
- **Note:** Discord notification from the reviewer script failed due to a malformed bot token (trailing newline in the token header). The review itself completed successfully — this is just the script's built-in notifier failing, not a MarkBot issue.

**Action needed:** The Discord bot token in the schema-governance config has a trailing newline. Mark should check `/Users/bigdaddy/lifeos/schema-governance/` config (likely a `.env` file) and strip any whitespace/newline from the `DISCORD_BOT_TOKEN` value.


Summary:
1 PR was processed but the Discord notification failed with a 404. Here's what happened:

- **1 pending PR found** and reviewed ✅
- **Discord notification failed** — status 404 (webhook or channel not found)

Mark, the schema PR reviewer ran and processed a PR, but the Discord notification didn't go through (404 error). You may want to check the webhook/channel config in `/Users/bigdaddy/lifeos/schema-governance/run-reviewer.sh` — looks like the Discord target might be stale or misconfigured.


Summary:
The reviewer ran and processed a PR that had been in-progress from a prior run. Here's what happened:

**Schema PR Reviewer — 5:45 PM run**

1 PR was resumed from queue and processed. Result: **auto-rejected** by the deterministic gate (no LLM review needed). Two PRs from earlier today also rejected:

**Rejected: `finance.amazon_order_detail`** (Amazon receipt/bookkeeping schema)
- ❌ Semantic manifest invalid: `time_column` must be str, got NoneType

**Rejected: `media` schema v2** (unified content tracking — TV, film, books, podcasts, etc.)
- ❌ `media.consumption` — `summary_query` must filter by `person_id` using `$1` parameter
- ❌ `media.item` — `person_id_column` must be str, got NoneType
- ❌ `media.item_analysis` — `person_id_column` must be str, got NoneType
- ❌ `media.item_person` — `time_column` must be str, got NoneType

**Separate issue:** Discord 404 on notification — the bot tried to post to channel `1478047216663789743` but got a 404. Likely a stale/wrong channel ID in the `MARK_DISCORD_CHANNEL` env var in Doppler.

Both PRs need their semantic manifests fixed before resubmission. The Discord notify failure means you wouldn't have been alerted either way — worth checking the Doppler config for `MARK_DISCORD_CHANNEL`.