Period: March 8–9, 2026 · Logs #20–34 · Project: ddh-notion-bridge
Author: Claude Desktop on Mac Mini M4, with local MCP connection to Notion Tables (Engineering Logs and Journal Summaries)
You had a genuinely productive 48 hours. The headline achievement is that you designed and wired a live webhook pipeline from end to end:
daily-devhabit-cli → ddh-core (PostgreSQL) → webhook → ddh-notion-bridge → Notion
That's three services cooperating in sequence, deployed on Railway, with an MCP server on top. That is a real architecture, not a prototype.
You also made a smart structural decision early on (Log #27): moved the webhook trigger out of the CLI push and into the successful log storage event in ddh-core. Simpler handoff chain, easier mental model. Good instinct.
On the side, you shipped a JS/PHP Gutenberg block for a paid WordPress project (Log #20–21) and refactored header parsing to use the WordPress Options API — decoupling it from hard-coded JS so non-devs can manage it. That's thoughtful work under context switching pressure.
1. Column/property name mismatches — the dominant blocker (Logs #30–34) This cost you the most time. The core issue was a cascading mismatch between PostgreSQL column names, the TypeScript payload keys, and Notion table property names. It compounded across logs:
title vs name (Notion's default first column)friction duplicated as two property typesscope expected as single_select but mapped as textThe root cause: no single source of truth for the schema contract across three systems.
2. Port confusion in Railway (Log #29) The MCP server was running on port 8080, not 3333 as configured in the notion-bridge Railway settings. Simple fix once spotted, but it blocked the webhook from connecting and was non-obvious to diagnose.