P0 integration parity roadmap backlog#679
Conversation
The parent roadmap needs a durable build-order source that both the API and settings UI can render, so the provider backlog now lives in typed roadmap data instead of issue-only prose. Constraint: #592 requires Linear integration categories to map to build issues or explicit parent tracking with setup, data model, runtime, permissions, admin UX, acceptance criteria, and validation plans. Confidence: high Scope-risk: moderate Tested: make check; make test; npx vitest run tests/integration-roadmap.test.ts tests/integrations-view.test.tsx; PLAYWRIGHT_CHROMIUM_EXECUTABLE_PATH=/snap/bin/chromium npx playwright test tests/e2e/integration-roadmap.spec.ts --project=chromium Not-tested: full make test-e2e was not run; focused Playwright coverage exercised the new roadmap through the real app route. Co-authored-by: OmX <omx@oh-my-codex.dev>
|
Controller intake: blocked before QA/merge. Current blocker:
Required fix:
|
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: fbc842d9fc
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| LINEAR_INTEGRATION_ROADMAP.filter((item) => item.provider).map((item) => [ | ||
| item.provider, | ||
| { | ||
| provider: item.provider as string, | ||
| name: providerDisplayName(item.provider as string), | ||
| description: providerDescription(item.provider as string, item.scope), | ||
| roadmapIssue: item.issue.number, |
There was a problem hiding this comment.
For providers with multiple roadmap entries, this Map construction overwrites the stored catalog value each time the provider appears while keeping the original key order. That means the user-facing setup text in /api/integrations points GitHub at #571 (issues sync) instead of the P0 install/setup issue #569, and Slack similarly ends up attached to the later Asks issue; admins following the catalog's setup requirement are sent to the wrong tracking issue. Use the first item per provider or an explicit catalog mapping for the setup issue.
Useful? React with 👍 / 👎.
|
Closing in favor of regeneration on the current architecture. This PR was authored against the pre-monorepo-split layout ( Review also flagged blocking security/correctness issues (varies per PR: SSRF, OAuth CSRF nonce never verified, full-table workspace scans, issue-number races, Re-generate from the spec in #592 on current |
1 participant
Summary
Verification
Closes #592