Feedback

app/[orgSlug]/[workspaceSlug]/roadmap/actions.ts:197 — promoteFeedbackToRoadmap() has no requireAuth() gate, unlike every other feedback server action (updateFeedbackStatus, updateFeedbackType, linkFeedbackToOpportunity, createFeedback all call requireAuth()). It also accepts BOTH feedbackId and workspaceId from the client without verifying the feedback item actually belongs to that workspace, and without verifying the caller has access to either. That combination makes it a cross-workspace write primitive: an unauthenticated caller can create a roadmap item in an arbitrary workspace and link an arbitrary feedback item to it. Fix: add requireAuth(), resolve workspaceId from the feedback record server-side rather than trusting the client, and verify the session user has access to that workspace. Add a regression test alongside the existing cases in __tests__/actions/feedback.test.ts. Found during planning for the DataGrid/Feedback work; deliberately kept out of that PR so it can land independently.

End-to-end production smoke test of the new create_feedback MCP tool (PR #111). Safe to close/delete.

I think its waiting until I select a launch style, but then even if I do that, I have to refresh the whole page to see the card move to the Launching column

Could have sworn we'd built this already, but PMs should be able to mark roadmap items as Private and then they won't show up on public roadmap.

It seems like voting isn't supported from the internal team. I think we should enable that (maybe could be a config option at the workspace level)

A long column means you scroll in a way you dont see the other phases making drag and drop impossible. Also, you can't tell which column is which anymore. I think the ideal view would be that the header of pages is fixed, and the kanban area has fixed headers as well, more of a desktop feeling app than a webpage. But we also need to maintain a working mobile view.

Agents can already answer how-to-use-Compass questions from the locally-installed compass skill, but end users navigating the app have no way to get help through an in-app/agent assistant grounded in Compass's own product documentation. Add a search-help capability so an assistant can answer questions like 'where do I find X', 'how do I create an OKR cycle', 'how do I promote a solution to the roadmap' etc. Suggested shape: an MCP tool such as search_help(query) / get_help(topic) (or an MCP read-only resource) that serves Compass's own product/usage documentation, so any agent (including an in-app assistant) can retrieve authoritative navigation and how-to guidance without relying on a locally-installed skill. Goal: help the humans find functionality, not just help agents operate on workspace data.

Like Help, Feedback, Org Settings etc

While fixing roadmap item b0780ac8 (test:e2e:functional broadly failing) in PR #76, found and fixed two real bugs (missing PanelProvider on org settings layout; hardcoded webServer port colliding across concurrent worktrees). After both fixes, 3 specs (feedback-attachments.spec.ts, portal-sso.spec.ts, roadmap-unscheduled-items.spec.ts) still fail intermittently, reproducing identically before/after the fixes, with the specific failing subset shifting run to run (a 4th run also caught assumption-experiment-linking.spec.ts and roadmap-private-items.spec.ts). Root cause looks like a shared-fixture race: all functional specs run against ONE seeded e2e-workspace and several mutate its Settings toggles (public roadmap, public feedback, portal auth required, SSO) using structural `[role="switch"]`.nth(N) locators. Under Playwright's default multi-worker parallelism, one spec's toggle change can shift switch indices (or flip auth-required state) out from under a different, concurrently-running spec. Tried forcing `workers: 1` for the functional project to eliminate the race entirely -- this made things dramatically worse (16 failures vs 4, ~23min vs ~2min), likely Turbopack/dev-server compile contention, so it was reverted rather than shipped. A real fix likely needs either per-worker workspace isolation (seed a fresh org/workspace per test instead of sharing one) or label-based/state-independent locators for the shared Settings toggles instead of positional nth().

While verifying a 1-line CSS fix to app/dashboard/page.tsx (unrelated to OKRs/Discovery/Experiments/Portal), ran pnpm test:e2e:functional per .claude/pr-guidelines.md as extra diligence. 16 of 18 specs failed with 90s timeouts waiting for buttons that never render; one error-context snapshot showed the page body was literally "Internal Server Error" (feedback-attachments.spec.ts, waiting on a switch role element). Reproduced identically on two separate runs in the same worktree, including after stopping a competing nextdev instance on a different port to rule out DB/port contention. Root cause not yet diagnosed (likely a DB seed/migration race in e2e/functional/global-setup.ts, or an env var missing in the isolated webServer). Worth investigating since it silently blocks the functional suite from providing any real signal on PRs that DO touch those journeys.

Settings > Branding lets you upload a workspace logo (stored via Vercel Blob, saved to brandingLogoUrl, resolved into ResolvedBranding.logoUrl). But WorkspaceThemeStyle explicitly skips rendering it (comment: logo-only branding has nothing to override at the CSS-variable level), and neither components/sidebar.tsx, components/mobile-header.tsx, nor the portal header (app/portal/[orgSlug]/[workspaceSlug]/layout.tsx, which still renders a hardcoded Compass icon) actually display logoUrl anywhere. The upload succeeds and persists but the logo is never shown to users.

The MCP tool catalog exposes add_assumption but no way to update or delete an assumption once created. During agentic processing, a wrong solutionId was passed to add_assumption by mistake, creating a stray placeholder assumption on an unrelated solution. There was no MCP tool to fix or remove it programmatically — it required manual cleanup in the UI. Request: add update_assumption (title, riskLevel, status) and delete_assumption tools, mirroring the update/delete coverage that roadmap items and docs already have.

When switching workspaces in Compass, the app does not reset the URL path — it keeps the UUID of the previously open discovery task (opportunity/solution) in the URL. Since that task ID does not exist in the newly selected workspace, the page fails to load with an error instead of redirecting to a valid route (e.g. the new workspace's discovery board root). Steps to reproduce: 1. Open a discovery task detail view in Workspace A (URL contains the task UUID). 2. Switch to Workspace B via the workspace switcher. 3. Compass keeps the same task UUID in the URL, now scoped to Workspace B, and the page errors instead of loading. Expected: switching workspaces should navigate to a valid route in the new workspace (e.g. drop the task-specific segment and land on the discovery/feedback root), not preserve a stale UUID that 404s or errors.

opportunityId can only be set on a RoadmapItem at creation time (via add_to_roadmap or promote_to_roadmap). Once a roadmap item exists, neither update_roadmap_item (MCP) nor any server action in app/[orgSlug]/[workspaceSlug]/roadmap/actions.ts (moveItem/archiveItem/updateSortOrder) supports setting opportunityId retroactively, and there is no edit UI for it either. Hit this while backfilling an OST under 4 pre-existing roadmap items in the Claude Threads workspace -- had to document the link in prose inside each item description instead of a real FK. Suggest adding opportunityId (and ideally solutionId/keyResultId) to update_roadmap_item plus a corresponding UI edit affordance on the roadmap card.

The opportunity detail page Experiments tab is read-only. Its empty state says: No experiments yet. Add assumptions to solutions and link experiments to them. But no UI affordance exists anywhere to do that linking. The natural flow — see a HIGH-risk assumption in the tree, click Test this assumption, get a pre-linked experiment — does not exist. The OST hierarchy visibly dead-ends at assumptions for UI users, which also feeds the first-time-users-dont-understand-OST opportunity (6de54118). Found during 2026-07-02 brainstorm code audit.

The create-experiment form on the Experiments board has no assumption picker (components/experiments/create-experiment-form.tsx has zero references to assumptions). Every experiment created through the UI is born with assumptionId null, so conclude_experiment has no assumption to auto-update and the OST validation loop silently breaks for human users. The only way to create a properly linked experiment today is the MCP create_experiment tool. Found during 2026-07-02 brainstorm code audit.

A Compass Feedback Agent task instructed the agent to call mcp__compass__* tools directly. ToolSearch found zero matching tools even though ~/.claude/claude-config/settings/personal.json has a correct compass MCP server entry (http, Bearer COMPASS_MCP_API_KEY) and the endpoint is reachable/working via direct curl/JSON-RPC (tools/list and tools/call both succeed with the same key). Only mcp__obsidian__* tools were connected in that session. Root cause not confirmed — either the Obsidian Claude Threads plugin runtime does not read personal.json's mcpServers block, or the compass server failed to connect silently at session start with no visible error. Worked around by writing a throwaway Node.js script that speaks the MCP JSON-RPC protocol directly over HTTP. This is a DX gap: agents have no visible signal when a configured MCP server fails to connect, and no way to detect it other than empty ToolSearch results.

The docs editor called getHTML() on save so the DB stored HTML. MCP get_doc returned raw HTML tags to LLMs making docs unreadable via MCP. Fixed in PR #23 with tiptap-markdown native storage. Suggest documenting that markdown is the canonical format for doc content so future contributors know the expected storage format.

When verifying PR #23 on the Vercel preview URL, the browser was redirected to vercel.com/login (Vercel SSO). No VERCEL_AUTOMATION_BYPASS_SECRET is configured, making it impossible to access previews from agent-browser or CI without a Vercel login. Had to fall back to running a local dev server for visual QA. Adding a bypass secret would fix this.

When creating the Claude Threads workspace via the MCP API, I had to guess whether feedbackEnabled and roadmapPublic were supported arguments. The tool description for create_workspace does not document these optional fields, so there is no way to know without trial and error. Would be helpful to document all accepted arguments in the tool schema description.

The portal feedback endpoint was POST-only. Agents submitting friction points had no way to check what they had already logged, so they submitted duplicate items on every session. A GET endpoint is needed to let agents deduplicate before posting. Fixed in PR #19.

During a workspace migration session, a duplicate org/workspace (golden-wealth/golden-wealth) was created at some earlier point and had no way to be removed through the UI. The only option was a code-level delete. This caused confusion when the dashboard showed two "Golden Wealth" entries. A delete workspace action (now in PR #18) addresses the workspace side, but there is still no way to delete an org itself.

After adding a second Playwright project (functional) to playwright.config.ts, the existing pnpm test:e2e script (playwright test with no --project flag) started discovering all projects and would attempt to run them. We had to change test:e2e to playwright test --project=screenshots to preserve the existing behaviour. This is a footgun: adding a new project silently changes what test:e2e runs without any warning. The scripts section of package.json should be reviewed whenever a new Playwright project is added.

When building the functional E2E suite, I wanted true schema isolation (e.g. compass_e2e_dev) so tests do not share tables with local dev data. But Playwright globalSetup runs before webServer starts, and prisma db push needs DATABASE_URL with ?schema=... appended which conflicts with the existing Aurora DSQL setup. There is no standard hook to run per-project DB provisioning. We had to fall back to org-slug isolation in the shared compass_dev schema. A Compass-level integration guide or a prisma db push --schema pattern for local e2e envs would prevent future confusion.

Running the pr-checklist and seeing `pnpm test:e2e` in the guidelines naturally reads as a functional E2E test gate. In practice, e2e/screenshots.spec.ts has no assertions — it just visits pages and saves PNGs for docs. This caused confusion during a verification session: the command was run expecting regression coverage but provides none. Renaming to `pnpm screenshots` or adding a prominent comment in the guidelines would prevent the same confusion for anyone following the checklist.

When implementing the SHIPPED roadmap state, the pnpm build step fails at page data collection because PGHOST/DATABASE_URL are not set in the worktree build environment. The TypeScript compile and type-check phases pass cleanly, but next build cannot proceed past SSR page data collection. This makes it impossible to confirm a clean production build in isolation without either mocking the DB layer at build time or injecting credentials into the worktree. Worktree-based development workflows need either a build-time env var injection mechanism or a way to skip SSR data collection for DB-dependent pages during CI verification.

After creating an org via MCP with no user seeded, there was no built-in way to fix the state. Had to ship a custom /api/admin/repair-workspace endpoint, redeploy twice, and call it manually. Compass should have a built-in admin repair tool (MCP or UI) that: looks up a user by email, adds them as org OWNER if missing, adds them as workspace ADMIN if missing. This is especially important for agent-bootstrapped workspaces where membership seeding is commonly missed.

When an agent calls create_workspace via MCP to bootstrap a new org, the calling user is never added to OrganizationMember or WorkspaceMember tables. The workspace is created in a vacuum — no one owns it. This means you cannot navigate to the workspace in the UI, and any subsequent MCP calls that check membership will fail silently. The fix required a separate repair endpoint. Root cause: the tool has no concept of a requesting user (no session context in MCP), so membership seeding has to be done explicitly. The tool should accept an optional ownerEmail param, or the MCP layer should accept a user context header and seed the OWNER automatically.

When working on the workspace dropdown fix, found that getOrgWorkspaces filters by organization slug, which means users with workspaces in multiple orgs only see the current org in the dropdown. There was no indication in the function name or signature that the scope was org-limited — the name suggests it returns all org workspaces for a user, not a cross-org view. A separate getUserWorkspaces function was needed. Consider either renaming getOrgWorkspaces to make the scope explicit, or adding a JSDoc comment explaining the intentional scope limitation so future callers understand the difference.

After creating a workspace via the MCP API (create_workspace), it does not show up in the org workspace list in the Compass UI. The workspace exists in the DB (confirmed via list_workspaces MCP tool returning the correct ID and data), but the user cannot see it when browsing the site. Navigating directly to /org/workspace works. This may be a stale cache, missing real-time update, or the workspace list page not fetching newly created workspaces. Affects discoverability — users think the create operation failed.

Running pnpm build in a fresh worktree (or any environment without DB credentials) fails during Next.js page data collection with: Neither DATABASE_URL nor PGHOST is set. This makes it impossible to verify a clean build before opening a PR without setting up the full DB environment. A build-time guard or mocked data layer for static analysis would help agents and contributors verify code changes without needing a live DB connection.

When building an agentic feedback processing workflow, I found the MCP tool catalog only had list_feedback. To take any action on feedback items (triage, status change, link to opportunity), I had to add three new tools (get_feedback_item, update_feedback_status, link_feedback_to_opportunity) manually. The feedback section of the MCP API should ship with a complete CRUD surface so agents can fully manage feedback without requiring code changes first.

Agents had no way to create a new workspace via MCP, requiring multiple failed workarounds (direct DB scripts, browser automation) before the user manually merged a PR to add the tool. create_workspace (and other admin ops like delete_workspace) should be in the MCP catalog so agents can complete workspace setup end-to-end.

When a secret key name is already in secretEnvKeys, request_secret returns alreadyExisted:true and never prompts the user — even when the stored value is wrong, revoked, or fake. There is no way for an agent to force re-prompting without manually editing data.json. This caused a session-long debugging spiral when the stored COMPASS_MCP_API_KEY was a fake value overriding the real keychain entry. Need a force:true parameter that always prompts regardless of existing state.

The Compass SKILL.md says `pnpm test` runs 181 unit + integration tests via Vitest. In practice the repo has no test files at all — only e2e/screenshots.spec.ts (Playwright). The test count and command description in the skill doc are stale. Either the tests were removed or the count was aspirational. Should either add unit tests or update the skill doc to reflect that the only automated tests are Playwright e2e.

When seeding a workspace via MCP, create_workspace returns the workspace name and slug but NOT the ID. To then call add_to_roadmap, you need the workspaceId (UUID). This forces a follow-up call to list_workspaces or get_workspace_summary to retrieve the ID. The create_workspace response should include the workspace ID so agents can chain calls without an extra round-trip.

POST /api/mcp requires both application/json and text/event-stream in the Accept header. Without it, the endpoint returns a JSON-RPC error with code -32000 and message 'Not Acceptable: Client must accept both application/json and text/event-stream'. This is not documented anywhere in the Compass README or API docs, making it very difficult for external callers to bootstrap. The error message is accurate but the requirement should be surfaced in docs.

When Vercel env vars for MCP_API_KEY and MIGRATION_SECRET drift from what is stored in 1Password (e.g. after rotation), the only signal is a silent 401/Unauthorized. There is no health-check endpoint or admin UI to verify which key the deployed app is actually using. This required two full redeployments to recover from during the GW roadmap migration. A GET /api/mcp/health endpoint that returns {keyPrefix: ..., ok: true} would let operators verify without revealing the full key.

When trying to create a new workspace via the MCP API, there was no tool available. The only workspace tools were list_workspaces and get_workspace_summary. This means any agentic workflow that needs to bootstrap a fresh workspace had to fall back to the Compass UI. A create_workspace tool (taking orgSlug, name, slug, optional description) was added in PR #10 to fix this.

When setting up a new workspace via /api/admin/workspaces, there was no way to enable feedbackEnabled or roadmapPublic during creation. These are core settings for public-facing portals (the main use case for workspace provisioning), so they should be first-class params in the POST body. Required patching the endpoint before the migration could proceed.

When migrating roadmap data, shipped items needed to be created via add_to_roadmap (which only accepts title/horizon/description) and then immediately archived via a second update_roadmap_item call. The tool should accept an optional status param so callers can create archived items in a single call.

When running pnpm test:coverage with @vitest/coverage-v8, the coverage report always shows 0% on Node.js v25.9.0. Root cause: Node 25 changed Profiler.takePreciseCoverage to return node:internal/ scheme URLs instead of file:// scheme URLs for user code. The filterResult function in @vitest/coverage-v8/dist/index.js rejects everything that does not start with file://, so no coverage data is recorded. The tests themselves pass fine (181/181). Workaround requires downgrading to Node 22 LTS or adding node: prefix handling to the coverage filter.

please let him know

Fixed in PR #5: Docs, Settings, and Help icons in MobileHeader now each display a 10px text label below the icon. Tappable area expanded to 56x40px targets.

Fixed in PR #5: DocsMobileDrawer component added. A Pages button in a slim toolbar above the doc content on mobile opens the full doc tree in a left-side Sheet drawer. Desktop layout unchanged.

The bottom nav has 5 items (OKRs, Discovery, Experiments, Roadmap, Feedback) and Docs is accessible via the mobile header icon — but there is no visual label on the header icon, only an icon. Users may not discover Docs unless they notice the BookOpen icon in the top-right.

The in-app /docs section has a tree sidebar that is hidden on mobile (< md) with no mobile alternative like a dropdown or drawer. Users on mobile cannot browse the doc tree to navigate between documents.

When working on mobile responsiveness across 9 page files, every single one had hardcoded p-8 padding with no responsive breakpoints, text-2xl with no mobile fallback, and board components (OpportunityBoard, ExperimentBoard, RoadmapBoard) had no overflow-x-auto wrapper. The scaffolding or generator should default to responsive padding (p-4 sm:p-6 md:p-8) and text sizing. This required touching 9 files to fix the same pattern, all of which would recur on any new page created from the same template.

The codebase uses new models (Squad, Doc, FeedbackItem, CustomField) added in recent migrations but the generated Prisma client was not committed. A fresh clone gets type errors on all of these models until prisma generate is run. Should be part of CI postinstall.

The MCP had add_to_roadmap but no way to read existing roadmap items. An agent building a roadmap plan would create duplicates because it cannot first check what already exists. Added list_roadmap_items with horizon and squad filters.

An agent using the MCP API has no entry point to find workspace IDs without already knowing them. There was no tool to go from org slug to workspace ID. Added list_workspaces(orgSlug) as fix. This should be part of the standard onboarding flow for new agent sessions.

When writing files using absolute paths that point to the main checkout (e.g. /Users/rickbowman/projects/compass/...) instead of the active worktree (e.g. /Users/rickbowman/projects/compass/.claude/worktrees/...), the write guard fires even though the intent is correct. The guard message is helpful but requires the user/agent to manually translate every path. It would be better if the guard could suggest the correct worktree-relative path automatically.

list_opportunities returns title, status, solution count, and KR name. But not the description. When scanning to avoid creating duplicates, agents can't tell from the list alone if an existing opportunity covers the same ground. Either include a description snippet in list output, or add a search/filter by title.

The public feedback REST endpoint exists and works. But agents have to drop out of MCP context to call it via curl/fetch. A submit_feedback(title, description) MCP tool would close the loop: agents encounter friction → immediately log it → continue workflow. This is the agentic flywheel for self-improvement. No workspace UUID needed since it could use the auth-scoped workspace context.

The current single shared API key means workspaceId must be passed to every tool explicitly. For single-workspace agents (99% of use cases), this is pure boilerplate that adds friction and creates room for error. Per-workspace keys (scoped at mint time, stored once in env) would clean up all tool signatures and make the API feel much more natural. Pattern: Stripe API keys are scoped to an account.

Building the meta-workspace required 15+ sequential MCP calls: create_opportunity → 5x add_solution → 4x add_assumption → create_experiment → add_to_roadmap. Each is a separate network round trip. A compound create_opportunity_with_solutions or a batch import tool would make seeding dramatically faster. Especially painful for agents bootstrapping a new workspace.

Only update_opportunity_status exists. Fixing a typo in title/description or changing customerSegment requires deleting and recreating the opportunity — losing all linked solutions, assumptions, and experiments. update_opportunity(opportunityId, {title?, description?, customerSegment?}) with all optional fields would solve this.

The MCP API has add_to_roadmap, promote_to_roadmap, and add_to_roadmap — but no way to read the roadmap back. An agent building a roadmap plan needs to know what's already on it before adding items. Currently the only read path is scraping the public portal HTML. This is a fundamental API asymmetry: agents can write but not read.

create_opportunity returns 'ID: <uuid>' (no bold) but add_solution returns '**ID:** <uuid>' (with bold markdown). This breaks any agent that tries to extract IDs via regex chaining. In the dogfood session, all 5 downstream add_solution calls failed with empty IDs because the extractor was written against the local source code format, not the deployed format. All tools should use the same format — ideally structured JSON fields.

Every single MCP tool requires a workspaceId (UUID). But there is no MCP-native way to discover that UUID from the org+workspace slug. During the meta-workspace dogfood session, this caused 15 minutes of digging through session history before finding it in a vault search. Suggested fix: add get_workspace_by_slug(orgSlug, workspaceSlug) tool that returns {workspaceId, name, activeOkrCycleId}. This is the #1 DX blocker for AI agents using Compass MCP.

takes up a whole vertical row for the drag control, and other full row for the ... menu