| 1 | /** |
| 2 | * What a project will have and does not yet: the pages the project menu |
| 3 | * shows as Soon, each with a page of its own saying what it will be. One |
| 4 | * place, so the menu and those pages never disagree. |
| 5 | * |
| 6 | * Each entry says what it is for, what it will do, and what to use today, |
| 7 | * so a Soon is a promise someone can read, not a greyed-out word. |
| 8 | */ |
| 9 | |
| 10 | export type RoadmapItem = { |
| 11 | /** In the address: `/<owner>/<project>/soon/<key>`. */ |
| 12 | key: string; |
| 13 | title: string; |
| 14 | /** |
| 15 | * Where it lives: a project page whose tabs it joins, or the workspace, |
| 16 | * for what spans projects (boards, the roadmap, packages, the fleet). |
| 17 | */ |
| 18 | section: "Code" | "Issues" | "Agents" | "Deployments" | "Observability" | "Security" | "Insights" | "Workspace"; |
| 19 | /** One line, for the menu's tooltip and the page's lead. */ |
| 20 | summary: string; |
| 21 | /** Why it matters, in two or three sentences. */ |
| 22 | why: string; |
| 23 | /** What it will do. */ |
| 24 | plans: string[]; |
| 25 | /** What to use until it exists: a project page, by its path under the project. */ |
| 26 | today?: { label: string; path: string }; |
| 27 | }; |
| 28 | |
| 29 | export const ROADMAP: RoadmapItem[] = [ |
| 30 | // --- Work --------------------------------------------------------------- |
| 31 | { |
| 32 | key: "board", |
| 33 | title: "Board", |
| 34 | section: "Workspace", |
| 35 | summary: "Issues and pull requests as a board, a table or a roadmap, with fields of your own.", |
| 36 | why: "One view of everything in flight, arranged the way your team thinks about it. Agents move the cards as they work, so the board is never out of date.", |
| 37 | plans: [ |
| 38 | "Board, table and roadmap views of the same items, saved and shared", |
| 39 | "Custom fields: status, priority, size, iteration, dates, anything", |
| 40 | "Group and filter by owner, outcome, label, agent or state", |
| 41 | "Cards move by themselves as agents open, revise and land changes", |
| 42 | "Across projects: one board can hold work from any of the workspace's projects", |
| 43 | "Attach a board to a project, so it shows on that project too", |
| 44 | ], |
| 45 | }, |
| 46 | { |
| 47 | key: "roadmap", |
| 48 | title: "Roadmap", |
| 49 | section: "Workspace", |
| 50 | summary: "Outcomes on a timeline, with their dependencies across projects.", |
| 51 | why: "An outcome is what should be true when the work is done. On a roadmap you see when each is expected, what it waits on in other projects, and how much has landed.", |
| 52 | plans: [ |
| 53 | "Outcomes as bars on a timeline, from start to target", |
| 54 | "Progress from merged work, not from guesses", |
| 55 | "Dependencies across projects, drawn from the project graph", |
| 56 | "Slip warnings when the work left outgrows the time left", |
| 57 | ], |
| 58 | today: { label: "Outcomes", path: "plans" }, |
| 59 | }, |
| 60 | { |
| 61 | key: "insights", |
| 62 | title: "Insights", |
| 63 | section: "Workspace", |
| 64 | summary: "How the whole workspace delivers: lead time, reviews, what agents do and what it costs, across every project.", |
| 65 | why: "Each project will have its own numbers. The workspace's put them side by side, so you can see which projects ship steadily, where work waits, and where the money goes.", |
| 66 | plans: [ |
| 67 | "Delivery metrics for every project, side by side", |
| 68 | "Where work waits: review, the merge queue, checks", |
| 69 | "Agents' share of merged changes, and how often it lands first time", |
| 70 | "Cost by project, by kind of work and per merged change", |
| 71 | ], |
| 72 | }, |
| 73 | // --- Code --------------------------------------------------------------- |
| 74 | { |
| 75 | key: "docs", |
| 76 | title: "Docs", |
| 77 | section: "Code", |
| 78 | summary: "Pages about the project that agents keep current as the code changes.", |
| 79 | why: "A wiki goes stale the day it is written. g1t's docs live with the code, and when a change makes a page wrong, an agent proposes the fix in the same pull request.", |
| 80 | plans: [ |
| 81 | "Pages written in Markdown, kept in the repository", |
| 82 | "Agents update pages a change makes wrong, in the same pull request", |
| 83 | "Architecture pages drawn from the code itself", |
| 84 | "Search across every project's docs", |
| 85 | ], |
| 86 | today: { label: "Files", path: "code" }, |
| 87 | }, |
| 88 | |
| 89 | // --- Agents ------------------------------------------------------------- |
| 90 | // At work, Sessions and Memory are built (see project-nav.ts), and so is |
| 91 | // the workspace's Agent fleet. |
| 92 | { |
| 93 | key: "playbooks", |
| 94 | title: "Playbooks", |
| 95 | section: "Agents", |
| 96 | summary: "How agents should work here: conventions, commands and checks.", |
| 97 | why: "Every project has its own way of doing things. Today every agent run already reads the repository's AGENTS.md and CLAUDE.md, at the root and in the directories it touches, and reviews read .g1t/review.md, all from the default branch. Playbooks build on those files with structure g1t can act on, not just read.", |
| 98 | plans: [ |
| 99 | "Instructions per kind of work: fixes, features, reviews, upgrades", |
| 100 | "Commands to build and test that g1t runs before every change, not just tells the agent about", |
| 101 | "Paths agents may not touch without a person, enforced on push", |
| 102 | "Learned from reviews: what people corrected becomes a proposed rule", |
| 103 | ], |
| 104 | today: { label: "Instructions, on Agents", path: "agents" }, |
| 105 | }, |
| 106 | |
| 107 | // --- Deployments ---------------------------------------------------------- |
| 108 | { |
| 109 | key: "environments", |
| 110 | title: "Environments", |
| 111 | section: "Deployments", |
| 112 | summary: "Staging, production and others, with approvers and branch rules.", |
| 113 | why: "Production and previews exist today. Environments add the rest: staging, QA, per-customer, each with its own variables, approvers and rules for what may deploy there.", |
| 114 | plans: [ |
| 115 | "Named environments with their own variables and secrets", |
| 116 | "Required approvers before a deploy", |
| 117 | "Branch rules: what may deploy where", |
| 118 | "Promote a deployment from one environment to the next", |
| 119 | ], |
| 120 | today: { label: "Deployments", path: "deployments" }, |
| 121 | }, |
| 122 | { |
| 123 | key: "releases", |
| 124 | title: "Releases", |
| 125 | section: "Deployments", |
| 126 | summary: "Tagged releases with notes written from what landed.", |
| 127 | why: "Release notes from the pull requests and sessions that made the release: what changed, why, and who or what changed it.", |
| 128 | plans: ["Notes drafted from merged work", "Assets and checksums attached", "Published to the project's page and a feed"], |
| 129 | today: { label: "Commits", path: "commits" }, |
| 130 | }, |
| 131 | |
| 132 | { |
| 133 | key: "flags", |
| 134 | title: "Feature flags", |
| 135 | section: "Deployments", |
| 136 | summary: "Turn features on per environment or per user, without a deploy.", |
| 137 | why: "Ship code dark and turn it on when ready, for some users first, at the edge, with no deploy.", |
| 138 | plans: ["Flags read at the edge by deployed apps", "Rollouts by percentage, user or environment", "Flags cleaned up by agents when fully on"], |
| 139 | today: { label: "Deployments", path: "deployments" }, |
| 140 | }, |
| 141 | |
| 142 | // --- Security ------------------------------------------------------------- |
| 143 | // The overview, secret scanning, code scanning, vulnerabilities and the |
| 144 | // dependency graph are built: see routes/repo/security-*.tsx. |
| 145 | { |
| 146 | key: "firewall", |
| 147 | title: "Firewall", |
| 148 | section: "Security", |
| 149 | summary: "Rules for who may reach the project's deployed apps.", |
| 150 | why: "Deployed apps run on Cloudflare. Rate limits, bot protection and IP rules, per app and environment.", |
| 151 | plans: ["Rate limits and bot protection", "IP and country rules", "Password-protected previews"], |
| 152 | today: { label: "Deployments", path: "deployments" }, |
| 153 | }, |
| 154 | |
| 155 | // --- Observe ------------------------------------------------------------ |
| 156 | { |
| 157 | key: "logs", |
| 158 | title: "Logs", |
| 159 | section: "Observability", |
| 160 | summary: "Requests, errors and CPU time of each deployment, and its logs.", |
| 161 | why: "Every deployed app's logs and numbers, by deployment, so a regression points at the change that caused it.", |
| 162 | plans: ["Live and searchable logs", "Requests, errors, latency and CPU by deployment", "Compare a preview with production"], |
| 163 | today: { label: "Deployments", path: "deployments" }, |
| 164 | }, |
| 165 | { |
| 166 | key: "errors", |
| 167 | title: "Errors", |
| 168 | section: "Observability", |
| 169 | summary: "Errors from the running app, each becoming an issue an agent can take.", |
| 170 | why: "An error in production should become a fix, not a dashboard. Each new error is grouped, explained, and turned into an issue with the context an agent needs.", |
| 171 | plans: ["Errors grouped with stack and request", "One click to an issue for an agent", "Incidents with a timeline and who was told"], |
| 172 | today: { label: "Issues", path: "issues" }, |
| 173 | }, |
| 174 | { |
| 175 | key: "uptime", |
| 176 | title: "Uptime", |
| 177 | section: "Observability", |
| 178 | summary: "Checks that the app answers, from around the world.", |
| 179 | why: "Know the app is down before your users tell you, and who was told.", |
| 180 | plans: ["Checks from many places", "Alerts by email and webhook", "A public status page"], |
| 181 | }, |
| 182 | { |
| 183 | key: "analytics", |
| 184 | title: "Web analytics", |
| 185 | section: "Observability", |
| 186 | summary: "Who visits the deployed apps, without cookies.", |
| 187 | why: "Visits, pages and referrers for each app, private by design, from Cloudflare's own analytics.", |
| 188 | plans: ["Visits, pages, referrers and countries", "No cookies, no personal data", "Per deployment and per preview"], |
| 189 | }, |
| 190 | |
| 191 | // --- Insights ------------------------------------------------------------- |
| 192 | { |
| 193 | key: "delivery", |
| 194 | title: "Delivery", |
| 195 | section: "Insights", |
| 196 | summary: "Lead time, deploy frequency, change failure rate and time to restore.", |
| 197 | why: "The four numbers that say how well a team ships, measured from what actually happened in g1t.", |
| 198 | plans: ["DORA metrics from merges and deployments", "Review and queue time", "Trends by week and by project"], |
| 199 | }, |
| 200 | { |
| 201 | key: "costs", |
| 202 | title: "Costs", |
| 203 | section: "Insights", |
| 204 | summary: "What the project costs, by agent run, sandbox, build and app.", |
| 205 | why: "Usage is charged by the workspace; here it is broken down for one project, so you can see what each part of the work costs.", |
| 206 | plans: ["Cost by kind of work and by issue", "Cost per merged change", "Budgets per project"], |
| 207 | }, |
| 208 | { |
| 209 | key: "impact", |
| 210 | title: "Agent impact", |
| 211 | section: "Insights", |
| 212 | summary: "How much of the work agents do, and how well.", |
| 213 | why: "The share of changes agents author, how often their work lands first time, and where people still step in.", |
| 214 | plans: ["Agents' share of merged changes", "First-time pass rate of checks and reviews", "Where people correct agents most"], |
| 215 | }, |
| 216 | ]; |
| 217 | |
| 218 | export function roadmapItem(key: string): RoadmapItem | undefined { |
| 219 | return ROADMAP.find((item) => item.key === key); |
| 220 | } |
| 221 | |
| 222 | export function roadmapIn(section: RoadmapItem["section"]): RoadmapItem[] { |
| 223 | return ROADMAP.filter((item) => item.section === section); |
| 224 | } |