MCP-first product memory. Strategy, decisions and gotchas your agents can read and write.
MCP-first product memory + orchestration for PMs.
Hands structured context, constraints and briefs out to agents over MCP. Multi-product, calm GUI.
What it does, in one line: your agents never start a task blind, and never finish one silently.
bluet_preflight turns a task into one cited brief: the rules not to break, the decisions that constrain it, the non-goals, the bet it serves, what is still undecided.bluet_check compares the plan or diff with everything decided and names the record each conflict collides with.bluet_debrief proposes what the session settled. The owner decides; nothing an agent says about itself is written directly.Honest scope today: the readers are GitHub (hosted) or a local checkout plus gh (bluet-mcp init). Heuristics find candidates; with ANTHROPIC_API_KEY set, a model judges them (Haiku 4.5 for decisions, Sonnet 5 for traps, briefs and contradictions) under a hard monthly cap (BLUET_LLM_CAP_USD, default $20), cached on its inputs. Without a key everything still works on the heuristics alone and says so. Analytics, Linear and other trackers are not read yet.
What it observes it records; what it infers it proposes. A release GitHub published is a fact, so it is written straight in. A pull request that reads like a decision, a warning that looks like a gotcha, and a positioning drafted from a README are all judgments — they arrive as proposals on Now, and accepting is what writes them. A measure and a falsifier are never proposed at all, because nothing in a repository holds them.
In the root of any repository — no account, no keys:
npx bluet-mcp init
It reads the README, the files written for agents (CLAUDE.md, AGENTS.md, CONTRIBUTING.md, the top of docs/) and, if gh is signed in, merged pull requests and issues. It prints what the product is, the traps your agents will now be told about, and the questions only you can answer.
Then install the Claude Code plugin:
claude plugin marketplace add bluet-dev/bluet-plugin
claude plugin install bluet@bluet
The plugin adds the MCP server, a session-start brief (silent in repositories Bluet does not know), a check before every commit (the staged change against what was decided: a blocking conflict stops the commit once and tells Claude why, so it asks you; the same commit run again goes through), a one-time request for a debrief after a session that edited files, and a skill that runs the loop above. npx bluet-mcp brief prints the same brief in a terminal. The plugin's source is plugin/; tool/publish-plugin.sh copies it to the public marketplace repo.
To see Bluet in Claude Code's status line (Bluet · my-app · 12 rules · 3 waiting · 1 caught this week):
npx bluet-mcp statusline --install
It writes a small reader to ~/.bluet/statusline.mjs and sets statusLine in ~/.claude/settings.json, unless you already have one, which it never overwrites. The reader only reads counts the session-start hook caches; it never touches the network.
To tell every agent that opens the repository to use Bluet, even without the plugin, npx bluet-mcp agents-md adds a marked block to AGENTS.md (or CLAUDE.md, when that is the file you use); re-running replaces only that block. It also prints a "Briefed by Bluet" README badge, if you want one.
Linking a machine that already used Bluet locally merges its memory: login adds every local decision and rule the workspace lacks (matched by repository, then name) and changes nothing that is there. npx bluet-mcp merge --dry-run shows what it would add.
Saves. When bluet_check blocks a plan, Bluet records a save ("caught"); if the same product's next check comes back clear within two hours, the agent changed course and the save is "averted". The Product Note on bluet.dev lists them, with what the data says (PostHog, CI on the default branch, the latest production deploy) and what needs you.
bluet-mcp sends anonymous usage counts so we can tell whether Bluet is useful: a random install id, event and tool names, success, outcome counts (how many records a brief cited, a check's verdict), the version and OS. Never content, questions, plans, repository or product names, paths or tokens. The first run says so once, on stderr.
To tell us what is missing: npx bluet-mcp feedback "your words" (sent even with telemetry off, because you asked for it to be sent). Full detail: bluet.dev/privacy.
Turn it off: npx bluet-mcp telemetry off, or set DO_NOT_TRACK=1 / BLUET_TELEMETRY=0. npx bluet-mcp telemetry shows what is sent and whether it is on.
Connect GitHub at bluet.dev and it reads every repository of the product, judges what it finds, and ends setup on the product as it reads it — with an agent briefed on a real open issue from your tracker. The last step issues a workspace token:
npx bluet-mcp login <token> # stored in ~/.bluet/config.json, mode 600
From then on the same binary, hooks and plugin read and write the hosted memory instead of ~/.bluet (npx bluet-mcp status, npx bluet-mcp logout). Any other MCP client can use the endpoint directly: https://bluet.dev/mcp with Authorization: Bearer <token>. It accepts only a workspace token; it is never open.
No account, no database, no keys. Point an MCP client at it:
{
"mcpServers": {
"bluet": { "command": "npx", "args": ["-y", "bluet-mcp"] }
}
}
Memory is stored locally in ~/.bluet — real Postgres, compiled to WASM via PGlite, so moving to a hosted database later is a row copy rather than a translation. Override the location with BLUET_DB_PATH.
Start by creating a product; every other tool needs one:
bluet_product_create { "name": "Acme" }
bluet_decision_record { "product": "acme", "title": "…", "decision": "…" }
Set DATABASE_URL to use hosted Postgres instead, and install pg alongside it (it is an optional dependency, so a local install does not pull it in).
pg (DATABASE_URL; Supabase in production)@modelcontextprotocol/sdk
npm run mcp (local IDE clients)npm run mcp:http on port 3100 (remote clients)cd /workspace/bluet # or your clone path
npm install
npm run dev
Open http://localhost:3000.
Seeding is explicit, not automatic: run npm run seed. It used to run on first boot against an empty database, which is wrong for a shared instance — and wrong on a stranger's machine, which must never receive someone else's demo products.
Sources (/sources) is the catalogue, in three tiers:
required; a source nobody has read from in three weeks is marked stale./stack instead: a source is a service Bluet could read evidence out of.A Connect button renders only where Bluet actually holds an auth config; everything else reads Not yet connectable rather than opening a window that fails. isConnectable derives from COMPOSIO_PROVIDERS, and a unit test asserts the two can never drift.
Settings (/settings) holds the rest:
BLUET_AUTH_BYPASS when keys are missing.PATCH /api/releases { product, id, bet_id?, decision_id? } attaches a release to the bet it serves or the decision that authorised it; null unlinks. Both ids are re-read from the named product first, so one workspace cannot attach its release to another's bet, and a release belonging to a different product 404s.
The selectors are on Timeline, one pair per release. They exist because the drift engine raises "Active bet without linked release" and "Release without linked decision" and used to send people to a Timeline that could only be read — the bet_id and decision_id columns have been in the schema since the first migration with no write path in any surface.
/intent)The page a human opens to ask what the product is for, and the page an agent reads over MCP for the same reason. It replaced /timeline, which showed Strategy, Bets, Roadmap and Releases as four boxes and left the reader to work out how they related — which is why the boxes were usually empty. /timeline redirects here.
One continuous argument: a north star, one measure, the bets under it, a Now/Next/Later horizon where every item names the bet it tests, and the versions shipped against them.
Every number on it is counted, never written. A bet's "6 decisions" is a query over decisions.bet_id, not a string in a fixture — a page that asserts its own evidence would break the rule it exists to state. A bet nothing cites reads "Nothing cites this yet", and evidenceLine returns null rather than "0 decisions".
| Field | Where it lives | Written by |
|---|---|---|
| North star, standfirst, the one measure | strategies.north_star, measure_* | bluet_strategy_set |
| Claim, reasoning, falsifier, conviction | bets.hypothesis, reasoning, falsifier, conviction | bluet_bet_upsert |
| What a bet was drawn from | decisions.bet_id, gotchas.bet_id | bluet_decision_record / bluet_gotcha_add, argument bet (by name or id) |
| Which bet an item or release serves | roadmap_items.bet_id, releases.bet_id | PATCH /api/releases, the selectors on Intent |
conviction (holding / testing / early) is deliberately not status. Status is lifecycle — active, paused, settled; conviction is how far a bet has been borne out. Folding them together would have made a bet marked "testing" stop matching listBets(id, "active"), which the drift engine depends on. Rows written before the column derive one from status rather than all claiming to be "early".
A bet with no falsifier says so, in the falsifier's own slot: "Not recorded. A bet with no falsifier cannot be lost, only defended."
A 52px rail pinned to the bottom edge showing one live event at a time. It exists because Bluet's most reassuring fact is invisible: agents are reading the memory right now. The header states that as a count; the rail lets you watch it.
Fed from the same stream as Activity — PulseRail owns no fetching, so the two surfaces cannot disagree about what happened. Tone carries the kind, using the existing signal tokens and never a sixth: purple an agent read, rose drift, amber a gotcha or stale source, sky a decision or feedback, emerald a release or a bet holding.
Rules it keeps: one line, never a stack (the moment it stacks it needs a dismiss affordance, an unread count and a settings panel); dwell floors at 1.6s (faster reads as a stock ticker, the wrong genre for judgment work); role="status" aria-live="polite"; and under prefers-reduced-motion it drops the ping and the slide and holds one line still. Nothing appears only here — every event also lands in Activity, so missing one costs nothing.
⚠️ Until this shipped, events were recorded for MCP calls, chat and sync only, so Activity was a stream in which people never appeared. Recording a decision, adding a gotcha, accepting or dismissing a proposal, and creating or linking a release now each write one (src/lib/record-activity.ts).
Three tiers, and the difference is Composio's, not ours. Checked against its live API, not its docs (GET /api/v3/toolkits/<slug> → composio_managed_auth_schemes).
All 37 catalogue entries were checked against Composio's own toolkit list (1,556 of them, paged), then each non-managed one re-checked individually — the list endpoint omits auth_config_details, so it reports Vercel as having no auth at all.
Managed — nothing to do (18). GitHub, GitLab, Bitbucket, Linear, Jira, Asana, Productboard, Sentry, PagerDuty, Supabase, Slack, Notion, Confluence, Discord, Teams, Drive, Intercom, Figma. One click today.
Needs an OAuth app of ours (4). Vercel, Railway, Datadog, Snowflake — OAUTH2 exists, Composio holds no app. One click once tool/setup-composio-oauth.mjs has run for each.
API key or bearer only (8). Shortcut, Render, Fly.io, PostHog, Grafana, Neon, CircleCI, Cloudflare — no OAUTH2 mode for Composio to broker.
No Composio toolkit at all (7). Netlify, PlanetScale, dbt, Storybook, Terraform, GitHub Actions, AWS.
⚠️ Our slug is not always Composio's: the catalogue says teams and gdrive, Composio says microsoft_teams and googledrive. The provider list holds our spelling and toComposioSlug translates at the boundary — holding Composio's there made isKnownToComposio("teams") false and rendered both as "Not yet connectable" while they were one click all along.
Our own OAuth app — Vercel. The toolkit supports OAUTH2; Composio just has no app of its own. One click needs a Vercel Integration we register:
https://backend.composio.dev/api/v1/auth-apps/add
COMPOSIO_API_KEY=… CLIENT_ID=… CLIENT_SECRET=… SUBDOMAIN=<integration-slug> node tool/setup-composio-oauth.mjs vercel
subdomain and means the Integration slug, not a hostname. A hostname there creates a config that looks fine and never completes.COMPOSIO_VERCEL_AUTH_CONFIG_ID. After this Composio holds the secret and the app never needs it again — which is why a pinned id alone makes isOneClickConnect true.--dry-run prints what it would send and changes nothing.
Not possible through Composio — PostHog. Its toolkit offers API_KEY and no OAUTH2 mode at all, so there is nothing to supply credentials to. PostHog itself does have OAuth applications; Composio simply does not expose that path, so one-click PostHog would mean building directly against PostHog rather than through the broker. Until then it takes a personal key (phx_…, not the phc_ project key) and a subdomain, collected on Composio's hosted form. The setup script refuses PostHog by name rather than creating something that cannot work.
POST /api/sources/sync?product=<slug> reads every repository attached to the product and compares its published releases against what the memory holds. It writes nothing. Each difference becomes a pending proposal on Now:
Observations are recorded; inferences are proposed. A release GitHub has published is a fact — it is written straight in with its evidence, exactly as detections go into Stack without asking. Measured on a real product, the alternative was forty releases whose bodies were all the same 202-character template, thirty-five of them sitting under "Needs your judgment". What reaches the queue is only what Bluet inferred, because an inference can be wrong in a way an observation cannot.
| Recorded directly, no approval | |
|---|---|
| A release with no record here | Written as shipped, with tag, body excerpt and URL as evidence |
A record still planned that GitHub published | Flipped to shipped — delivery is the external system's to own |
| A shipped record pointing at nothing | Its evidence link attached |
| Proposed for judgment | Accepting does |
|---|---|
A warning in CLAUDE.md / AGENTS.md | Writes the gotcha, graded by how absolute the warning is, with the file and section as evidence |
| A merged pull request that reads like a decision | Writes the decision, with the PR body as rationale and the PR as evidence |
Where gotchas come from. CLAUDE.md and AGENTS.md — the files a team already writes for its agents, which is exactly the reader Bluet serves. One in a real repository opens "the things that have actually gone wrong here, so they don't go wrong twice", which is a gotcha list already written in a file nothing read.
Lines are joined back into sentences before scanning, because these files are hard-wrapped at eighty columns and scanning line by line reads fragments. Severity is graded by how absolute the warning is: must never and never are critical, do not and trap are warnings. Code fences, tables, bare links and a file describing itself are skipped. Measured on Captain Kill Switch: 19 traps across three files, including "Never run a kill sweep on the machine driving your session" and "Silence must never read as health."
Which pull requests are raised. Only merged ones — an open PR is an argument still being had, and a closed-unmerged one is an argument somebody lost. A PR has to clear a score built from decision language (decided, instead of, trade-off, ADR), carry a body of at least 180 characters, and not look routine (bump, chore, revert, a bare version number). The proposal says which markers fired, so the judgment can be checked rather than trusted.
Calibrated against 87 merged pull requests across Captain Kill Switch's repositories: 14 raised, 16%. The failure mode is not missing one — it is raising forty, which is the product's own second bet: "teams that dismiss more than half of what we raise are being shown noise wearing a badge."
The conflict rule it implements: Bluet owns intent, external systems own delivery status. A pre-release never flips a record to shipped — a beta is not a delivery.
A repo the connection cannot read is named in the response and in the UI, with the reason — Composio's proxy answers a GitHub 403/404 with a normal response carrying the status, so an unapproved organisation and a repo with no releases are the same silence unless the status is read. Reporting the first as the second tells someone their org approval worked when it did not.
Drafts are skipped. Dedupe is on owner/repo#<release id> and remembers dismissed proposals too, so judging one is final and a poll never re-asks. Onboarding runs this once, so a new product's first Now view holds real proposals rather than an empty queue; Sources → Check for changes runs it again.
⚠️ Until this existed createSyncProposal had no callers at all — the queue was fed by npm run seed and nothing else.
Orchestration out from Agents (/agents):
POST /api/briefs/push { "product": "pasiv", "agentName": "growth" } or { "product": "pasiv", "all": true }webhook genuinely delivers, by POSTing to a URL you register. mcp_poll (the default) and clipboard only write a brief_deliveries row — there is no queue and nothing is copied; agents read the current brief with bluet_brief_get whether or not Push was ever pressed.bluet_brief_push (same server logic)Toast examples: Pushed to growth · webhook 200 · Queued for MCP (agents call bluet_brief_get)
npm run mcp
Used by Claude Desktop, Claude Code, Cursor, Windsurf, VS Code Copilot, Cline, Continue, Goose, etc.
npm run mcp:http
Listens on 0.0.0.0:3100 by default:
| Endpoint | Purpose |
|---|---|
http://127.0.0.1:3100/mcp | Streamable HTTP MCP (preferred) |
http://127.0.0.1:3100/sse | Legacy SSE (older clients) |
http://127.0.0.1:3100/messages | Legacy SSE message POST |
http://127.0.0.1:3100/health | Liveness |
Optional env:
| Variable | Meaning |
|---|---|
BLUET_MCP_HTTP_PORT | Port (default 3100) |
BLUET_MCP_HTTP_HOST | Bind host (default 0.0.0.0) |
BLUET_MCP_TOKEN | If set, require Authorization: Bearer <token> |
BLUET_PUBLIC_URL | Public base URL shown in GUI /sources (e.g. tunnel) |
DATABASE_URL | Required. Postgres connection string |
BLUET_MCP_ALLOWED_HOSTS | Comma-separated Host allowlist when you want DNS-rebinding checks |
Smoke tests:
npm run mcp:smoke # DB + tool surface via shared layer
npm run mcp:http:smoke # spins HTTP server, initialize + tools/list
Bluet MCP is bidirectional:
bluet_context_get, bluet_products_list, bluet_constraint_list, bluet_*_list / _get, bluet_brief_get, bluet_gotcha_searchbluet_decision_record, bluet_gotcha_add, bluet_brief_set, bluet_ingest, bluet_roadmap_upsert, bluet_release_upsertThe GUI Settings page (/settings) has copy-paste cards for each client. Summary:
Stdio mcpServers entry:
{
"mcpServers": {
"bluet": {
"command": "npm",
"args": ["run", "mcp"],
"cwd": "/absolute/path/to/bluet"
}
}
}
Or:
{
"mcpServers": {
"bluet": {
"command": "npx",
"args": ["tsx", "src/mcp/server.ts"],
"cwd": "/absolute/path/to/bluet"
}
}
}
.vscode/mcp.json:
{
"servers": {
"bluet": {
"type": "stdio",
"command": "npm",
"args": ["run", "mcp"],
"cwd": "/absolute/path/to/bluet"
}
}
}
npm run mcp:httphttp://127.0.0.1:3100/mcp (or your BLUET_PUBLIC_URL + /mcp)BLUET_MCP_TOKEN is set, send Authorization: Bearer <token>HTTP-shaped config some clients accept:
{
"mcpServers": {
"bluet": {
"url": "http://127.0.0.1:3100/mcp"
}
}
}
Two ways, one codebase.
Local, no account — the MCP server runs against PGlite in ~/.bluet, with
no hosted database, no sign-in and no broker key:
npm run mcp # stdio, for an agent config
Override the location with BLUET_DB_PATH. Nothing is seeded: a fresh install
starts empty, and bluet_product_create is the first tool to call.
Hosted — set DATABASE_URL and the same code talks to Postgres instead,
which is what the web app uses. See .env.example.
| Tool | Direction | Purpose |
|---|---|---|
bluet_preflight | read | Call first, before changing code: given a task (and files), the rules, decisions, non-goals, bet and open questions that bear on it — one cited brief |
bluet_check | read | Check a plan or diff against everything decided; each conflict cites the record it collides with |
bluet_debrief | write | At the end of work: the decisions made and traps hit, proposed for the owner; the summary is checked and a contradiction is raised as drift |
bluet_brief_today | read | The last day: what waits on the owner, recent activity, the rules agents are told, unanswered questions |
bluet_proposals_list | read | What waits for the owner's judgment, with evidence links |
bluet_proposal_judge | write | Accept or dismiss one proposal — only on the owner's say-so |
bluet_repo_ingest | write | Record a repository read on the caller's machine (what linked npx bluet-mcp init uploads) — for repositories GitHub will not let bluet.dev read |
bluet_products_list | read | List all products in Bluet memory |
bluet_context_get | read | Get full product context (strategy, bets, roadmap, releases, decisions, gotchas, briefs, constraints) |
bluet_decision_list | read | List decisions for a product |
bluet_decision_get | read | Get a single decision by id |
bluet_gotcha_list | read | List gotchas for a product |
bluet_gotcha_search | read | Search gotchas by text query |
bluet_drift_list | read | List drift: where product memory and the outside world disagree. Each item carries the tool call that resolves it, or why none exists. |
bluet_roadmap_list | read | List roadmap items for a product |
bluet_release_list | read | List releases for a product |
bluet_brief_get | read | Get an agent brief (or all briefs if agent_key omitted) |
bluet_constraint_list | read | List derived constraints from strategy non-goals/principles and agent briefs |
bluet_decision_record | write | Record a product decision (optionally superseding a prior one) |
bluet_decision_update | write | Edit fields on an existing product decision without creating a new version |
bluet_product_create | write | Create a product to hold memory. Required before anything else on a fresh install. |
bluet_strategy_set | write | Set the product strategy. Supersedes the current one, keeping the previous version linked rather than overwriting it. |
bluet_bet_list | read | List bets for a product |
bluet_bet_upsert | write | Create or update a bet — a hypothesis the product is testing |
bluet_gotcha_add | write | Add a gotcha / trap / tribal knowledge note |
bluet_roadmap_upsert | write | Create or update a roadmap item |
bluet_release_upsert | write | Create or update a release plan |
bluet_brief_set | write | Create or update an agent brief |
bluet_brief_push | write | Push agent brief(s) to endpoints (webhook) and/or queue for MCP poll. Always upserts the canonical brief store and records a delivery row. |
bluet_ingest | write | Ingest a note/url/payload into Bluet as decision |
| Route | |
|---|---|
/ | Now — bets, next release, decisions, briefs |
/timeline | Strategy → bets → roadmap → releases |
/decisions | List + create |
/gotchas | List + search + create |
/agents | Briefs + Push / Push all + endpoints |
/sources | One-click auth, OAuth, MCP copy cards |
Product switcher (top-left pills) scopes everything to the selected product.
sync_proposals appear after migrate for Drift on Now.Re-seed from empty (wipes local DB):
npm run db:reset
db:reset TRUNCATEs every table and re-seeds, so it refuses to run without
BLUET_ALLOW_RESET=1:
BLUET_ALLOW_RESET=1 npm run db:reset
After changing src/db/seed.ts, run npm run seed (idempotent) or the reset above.
Bluet uses Clerk for product GUI auth (App Router).
NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY and Secret key → CLERK_SECRET_KEY into .env.local (see .env.example).NEXT_PUBLIC_CLERK_SIGN_IN_URL=/sign-inNEXT_PUBLIC_CLERK_SIGN_UP_URL=/sign-upnpm run dev. Middleware protects Now / Chat / Decisions / Gotchas / Activity / Sources / Settings and APIs. Public: /sign-in, /sign-up, /api/health.Local smoke without keys: set BLUET_AUTH_BYPASS=1. Middleware skips Clerk; a bypass workspace is used. A banner explains the mode. If keys are simply missing (no bypass), the app still boots and shows a Set Clerk keys banner instead of crashing.
Multi-tenant (light): Clerk orgId (preferred) or userId maps to an Bluet workspaces row. First login creates one workspace per user/org and claims orphan products (so seed Pasiv data stays visible).
Pasiv canary flow:
unverified, which is not connected. Vercel can become genuinely one-click with a Vercel Integration's own client id and secret; PostHog cannot — it exposes no third-party OAuth at all.package.json, vercel.json, env examples, README, etc.COMPOSIO_API_KEY in .env.local (never commit the value).COMPOSIO_GITHUB_AUTH_CONFIG_ID (managed OAuth)COMPOSIO_POSTHOG_AUTH_CONFIG_ID (API_KEY)COMPOSIO_VERCEL_AUTH_CONFIG_ID (API_KEY — no managed OAuth)COMPOSIO_LINEAR_AUTH_CONFIG_ID (optional)/sources), Connect GitHub from the catalogue, then pick a repo in Settings. Detected sources appear under Found in your code.After login (or bypass), Settings → MCP access can generate a workspace Bearer token (shown once). HTTP MCP (npm run mcp:http) accepts:
BLUET_MCP_TOKEN, ormcp_tokens (sha256 hash stored; raw token never persisted)If neither global nor any workspace tokens exist, HTTP MCP stays open (dev-friendly). Workspace tokens attach workspace context for future scoping.
Stdio MCP (npm run mcp) is unchanged and does not require these tokens.
Copy snippets on Sources use BLUET_PUBLIC_URL for the public /mcp URL.
| Variable | Required for |
|---|---|
NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY | GUI auth |
CLERK_SECRET_KEY | GUI auth |
BLUET_AUTH_BYPASS | Local smoke without Clerk |
COMPOSIO_API_KEY | PostHog / GitHub / Vercel / Linear Composio Connect |
COMPOSIO_POSTHOG_AUTH_CONFIG_ID | Optional pin PostHog auth config |
COMPOSIO_GITHUB_AUTH_CONFIG_ID | Optional pin GitHub auth config |
COMPOSIO_VERCEL_AUTH_CONFIG_ID | Optional pin Vercel auth config |
COMPOSIO_LINEAR_AUTH_CONFIG_ID | Optional pin Linear auth config |
BLUET_PUBLIC_URL | Sources MCP URL snippets |
BLUET_MCP_TOKEN | Optional global HTTP MCP auth |
Copy .env.example → .env.local and fill values.
Bluet owns intent: strategy, bets, decisions, gotchas, and agent briefs/constraints.
Connected systems are evidence. Accepting a proposal updates status and links only — never strategy or decision body text, and that rule is enforced in code rather than only stated here.
Not yet true: nothing currently generates proposals. The structural drift signals (a bet with no release, a shipped release with no decision, a stale connection) are computed and real; the landscape-sourced proposals are seeded fixtures on the canary product.
Conflict rule: Bluet wins on intent; external systems win on delivery status until a Decision is recorded.
The Now page shows a Drift panel when pending sync proposals or simple heuristics fire (e.g. active bet with no linked release, release without a decision, stale source connection). Empty state: “No drift — Bluet and landscape agree.”
Demo: open Pasiv on / after migrate — two pending GitHub proposals are seeded for accept/dismiss via POST /api/sync-proposals.
Intended GitHub path: memory-like-bluet/bluet.
npm test # unit + logic (vitest)
npm run e2e # self-driving browser suite (playwright)
npm run e2e:update # refresh visual baselines — read the diff before accepting
npm run e2e:report # open the last HTML report
npm test is offline and deterministic — GitHub reads are mocked, no database.
The browser suite boots the app locally with BLUET_AUTH_BYPASS=1, which is
safe because bypassAllowed() refuses on any Vercel deployment and whenever
NODE_ENV=production. Specs are read-only and assert against their own
e2e-fixture product in the bypass workspace, never real product memory.
Point it at the transaction pooler, not the session pooler:
E2E_DATABASE_URL='postgresql://…@…pooler.supabase.com:6543/postgres' npm run e2e
The session pooler (:5432) holds one Postgres connection per client and
exhausts under a concurrent run — the symptom is /api/health returning 503
and every page reporting 500s, which looks exactly like a product bug.
FAQs
MCP-first product memory. Strategy, decisions and gotchas your agents can read and write.
The npm package bluet-mcp receives a total of 2,186 weekly downloads. As such, bluet-mcp popularity was classified as popular.
We found that bluet-mcp demonstrated a healthy version release cadence and project activity because the last version was released less than a year ago. It has 1 open source maintainer collaborating on the project.
Company News
Socket is joining the OpenJS Security Stewardship Program to fund Node.js vulnerability research, maintainer remediation, and security releases.
Security News
Two compromised GitHub Actions were re-enabled with malicious tags intact, exposing thousands of downstream repositories to Mini Shai-Hulud.
Research
/Security News
A malicious Firefox extension fetches its payload after installation to evade detection, steal Google session cookies, and automate account takeover.