🌱 refactor(schema): seed default policy keys at DB init, not by bro#129
Merged
Conversation
User feedback: 'Why don't make insert the default values by sql itself when setup DB? It can be part of the DB setup process?' — and 'Why we waste so many lines on First-action chain?' Both addressed. ## Schema changes `mcp/trajectory-server/src/schema.sql` — INSERT OR IGNORE for the 3 default policy keys (branching_model=github-flow, pr_target=main, protected_branches=["main"]) right after the plugin_config CREATE. Idempotent, safe to re-run on existing DBs (no overwrite of user choices). ## CLAUDE.md compression First-action chain shrinks from 12 lines to 4: ## Activation routine (every triggered message, no shortcuts) Two parallel MCP reads, then welcome banner, then the actual ask: - identity_get(agent='bro') — name (or null = user hasn't reonboarded yet) - issue_resume(agent='bro') — pending work, if any Policy keys are seeded at DB init; fetch via config_get only when needed. Welcome banner shrinks from 3 variants to 2 (no 'first contact' variant needed — pending-work or idle is enough). `tmb_defaults_applied` ledger event removed entirely. Schema seeding is silent; bro only logs ledger events for decisions it actually makes. ## Test updates - `tests/hooks/git-guards.test.sh` — drop the redundant INSERT INTO plugin_config (now schema-seeded; INSERT was hitting UNIQUE constraint). - `mcp/trajectory-server/src/test/config.test.ts` — three tests updated: 'config_list with 0 entries' → 'config_list returns schema-seeded defaults on a fresh DB'; the +1 and +3 entry tests now assert the seeded keys appear alongside user-set entries. - `mcp/trajectory-server/src/test/schema.test.ts` — 'plugin_config has zero rows on init' → 'plugin_config has the 3 schema-seeded default policy keys on init' (with concrete value assertions). - `tests/mcp-integration/agent-bro-workflow.test.mjs` — DELETED. It tested the removed first-run onboarding sequence. ## Fixture updates - `onboarding-anonymous.sql` — drop the redundant INSERT INTO plugin_config + the tmb_defaults_applied ledger row. Fixture now only seeds the deliberately-blank identity row. - `onboarding-named.sql` — drop the redundant config inserts; rename the ledger event from `tmb_defaults_applied` to `tmb_user_named` (which is what the fixture actually represents — user explicitly set their name via tmb_reonboard). ## Doc updates - FLOWS.md Flow 1 redrawn — sequence diagram now shows just the two parallel reads + welcome banner. No bro-side default writes. - ENUMS.md — drop `tmb_defaults_applied` (no longer fired anywhere). - tests/manual/setup.md — expected-state description updated. ## Local verification bash tests/run-all.sh → All test layers passed (L1 + L2 + L3).
This was referenced Apr 26, 2026
Closed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
User feedback: 'Why don't make insert the default values by sql itself when setup DB? It can be part of the DB setup process?' and 'Why we waste so many lines on First-action chain?'
Both addressed.
Schema seeds defaults at DB creation
`mcp/trajectory-server/src/schema.sql` — `INSERT OR IGNORE` for the 3 default policy keys right after the `plugin_config` CREATE. Idempotent, safe to re-run on existing DBs (no overwrite of user choices).
CLAUDE.md first-action chain: 12 lines → 4 lines
Before:
After:
`config_get` removed from the always-call set — bro fetches lazily when a specific key matters.
Welcome banner: 3 variants → 2
Dropped the 'first contact' variant. Pending-work-or-idle is enough; the user knows bro is active because of the 'Entering bro mode.' announcement and the banner that follows.
`tmb_defaults_applied` ledger event removed entirely
Schema seeding is a system action, not a bro decision. The ledger is for events bro emits; it shouldn't be polluted with init-state markers.
Test fixes (all caught locally)
Fixture updates
Doc updates
Local verification
`bash tests/run-all.sh` → `All test layers passed (L1 + L2 + L3).`