g1t/apps/web/app/lib/roadmap.ts

273 lines12,817 bytesCodeBlame

Pick any line to see why it is the way it is: the commit, the pull request and issue it came from, and what the agent was thinking.

A menu shaped by how g1t works, Soon pages for every promise, and sudo for sales1/**
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
10export type RoadmapItem = {
11 /** In the address: `/<owner>/<project>/soon/<key>`. */
12 key: string;
13 title: string;
A flat project menu with Code first, views as tabs, and Stripe for every owner14 /**
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 */
Observability gets its own page; tabs never overflow18 section: "Code" | "Issues" | "Agents" | "Deployments" | "Observability" | "Security" | "Insights" | "Workspace";
A menu shaped by how g1t works, Soon pages for every promise, and sudo for sales19 /** 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
29export const ROADMAP: RoadmapItem[] = [
30 // --- Work ---------------------------------------------------------------
31 {
Packages, with a container registry on g1t.sh; workspaces deleted whole and kept 30 days; Members for every member32 key: "teams",
33 title: "Teams",
34 section: "Workspace",
35 summary: "Groups of members, given roles on repositories together.",
36 why: "Give a group a role on many repositories at once, mention it, and request its review, instead of adding people one by one.",
37 plans: ["Teams with members and maintainers", "Repository roles for a team", "@team mentions and review requests"],
38 },
39 {
A menu shaped by how g1t works, Soon pages for every promise, and sudo for sales40 key: "board",
41 title: "Board",
A flat project menu with Code first, views as tabs, and Stripe for every owner42 section: "Workspace",
A menu shaped by how g1t works, Soon pages for every promise, and sudo for sales43 summary: "Issues and pull requests as a board, a table or a roadmap, with fields of your own.",
Say what g1t does, not whom it is like44 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.",
A menu shaped by how g1t works, Soon pages for every promise, and sudo for sales45 plans: [
46 "Board, table and roadmap views of the same items, saved and shared",
47 "Custom fields: status, priority, size, iteration, dates, anything",
48 "Group and filter by owner, outcome, label, agent or state",
49 "Cards move by themselves as agents open, revise and land changes",
A flat project menu with Code first, views as tabs, and Stripe for every owner50 "Across projects: one board can hold work from any of the workspace's projects",
51 "Attach a board to a project, so it shows on that project too",
A menu shaped by how g1t works, Soon pages for every promise, and sudo for sales52 ],
53 },
54 {
55 key: "roadmap",
56 title: "Roadmap",
A flat project menu with Code first, views as tabs, and Stripe for every owner57 section: "Workspace",
A menu shaped by how g1t works, Soon pages for every promise, and sudo for sales58 summary: "Outcomes on a timeline, with their dependencies across projects.",
59 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.",
60 plans: [
61 "Outcomes as bars on a timeline, from start to target",
62 "Progress from merged work, not from guesses",
63 "Dependencies across projects, drawn from the project graph",
64 "Slip warnings when the work left outgrows the time left",
65 ],
66 today: { label: "Outcomes", path: "plans" },
67 },
68 {
69 key: "milestones",
70 title: "Milestones",
A flat project menu with Code first, views as tabs, and Stripe for every owner71 section: "Issues",
A menu shaped by how g1t works, Soon pages for every promise, and sudo for sales72 summary: "Dates to land outcomes by, with what is left and what is at risk.",
73 why: "A milestone groups the issues that must land together, by a date. g1t shows what remains and which agent or person holds each part.",
74 plans: [
75 "Issues and outcomes grouped under a due date",
76 "Burn-down from merged pull requests",
77 "At-risk items flagged before the date, not after",
78 ],
79 today: { label: "Issues", path: "issues" },
80 },
81
82 // --- Code ---------------------------------------------------------------
83 {
84 key: "branches",
85 title: "Branches",
86 section: "Code",
87 summary: "Every branch: who is on it, how far behind it is, and its preview.",
88 why: "With agents opening branches by the dozen, a list of names is not enough. Each branch shows its pull request, its checks, its live preview and how stale it is.",
89 plans: [
90 "Branches with their pull request, checks and preview address",
91 "Ahead and behind the default branch, with one-click catch-up by an agent",
92 "Protection rules: required checks, reviews and the merge queue",
93 "Stale branches cleaned up on a schedule you set",
94 ],
95 today: { label: "Pull requests", path: "pulls" },
96 },
97 {
98 key: "tags",
99 title: "Tags",
100 section: "Code",
101 summary: "Tags, and the releases made from them.",
102 why: "A tag marks a version of the code. Each links to its release notes and to the deployment that shipped it.",
103 plans: ["Tags with their commit, release and deployment", "Signed tags verified", "Rules for who may create and move them"],
104 today: { label: "Commits", path: "commits" },
105 },
106 {
107 key: "compare",
108 title: "Compare",
109 section: "Code",
110 summary: "Any two branches, tags or commits, side by side.",
111 why: "See exactly what changed between two points, with the sessions and pull requests that changed it.",
112 plans: ["Diff any two refs", "The pull requests and agent sessions between them", "Open a pull request from the comparison"],
113 today: { label: "Commits", path: "commits" },
114 },
115 {
116 key: "docs",
117 title: "Docs",
118 section: "Code",
119 summary: "Pages about the project that agents keep current as the code changes.",
120 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.",
121 plans: [
122 "Pages written in Markdown, kept in the repository",
123 "Agents update pages a change makes wrong, in the same pull request",
124 "Architecture pages drawn from the code itself",
125 "Search across every project's docs",
126 ],
127 today: { label: "Files", path: "code" },
128 },
129
130 // --- Agents -------------------------------------------------------------
Agents and memory, checks and conflicts, profiles, slug renames, custom domains131 // At work, Sessions and Memory are built (see project-nav.ts), and so is
132 // the workspace's Agent fleet.
A menu shaped by how g1t works, Soon pages for every promise, and sudo for sales133 {
134 key: "playbooks",
135 title: "Playbooks",
136 section: "Agents",
137 summary: "How agents should work here: conventions, commands and checks.",
Agents get guardrails, run credentials, an audit log, a context hub, repository instructions and mentions; security upkeep; snake_case API138 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.",
A menu shaped by how g1t works, Soon pages for every promise, and sudo for sales139 plans: [
140 "Instructions per kind of work: fixes, features, reviews, upgrades",
Agents get guardrails, run credentials, an audit log, a context hub, repository instructions and mentions; security upkeep; snake_case API141 "Commands to build and test that g1t runs before every change, not just tells the agent about",
142 "Paths agents may not touch without a person, enforced on push",
143 "Learned from reviews: what people corrected becomes a proposed rule",
A menu shaped by how g1t works, Soon pages for every promise, and sudo for sales144 ],
Agents get guardrails, run credentials, an audit log, a context hub, repository instructions and mentions; security upkeep; snake_case API145 today: { label: "Instructions, on Agents", path: "agents" },
A flat project menu with Code first, views as tabs, and Stripe for every owner146 },
147
148 // --- Deployments ----------------------------------------------------------
149 {
A menu shaped by how g1t works, Soon pages for every promise, and sudo for sales150 key: "environments",
151 title: "Environments",
A flat project menu with Code first, views as tabs, and Stripe for every owner152 section: "Deployments",
A menu shaped by how g1t works, Soon pages for every promise, and sudo for sales153 summary: "Staging, production and others, with approvers and branch rules.",
154 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.",
155 plans: [
156 "Named environments with their own variables and secrets",
157 "Required approvers before a deploy",
158 "Branch rules: what may deploy where",
159 "Promote a deployment from one environment to the next",
160 ],
161 today: { label: "Deployments", path: "deployments" },
162 },
163 {
164 key: "releases",
165 title: "Releases",
A flat project menu with Code first, views as tabs, and Stripe for every owner166 section: "Deployments",
A menu shaped by how g1t works, Soon pages for every promise, and sudo for sales167 summary: "Tagged releases with notes written from what landed.",
168 why: "Release notes from the pull requests and sessions that made the release: what changed, why, and who or what changed it.",
169 plans: ["Notes drafted from merged work", "Assets and checksums attached", "Published to the project's page and a feed"],
170 today: { label: "Commits", path: "commits" },
171 },
Packages, with a container registry on g1t.sh; workspaces deleted whole and kept 30 days; Members for every member172
A menu shaped by how g1t works, Soon pages for every promise, and sudo for sales173 {
174 key: "flags",
175 title: "Feature flags",
A flat project menu with Code first, views as tabs, and Stripe for every owner176 section: "Deployments",
A menu shaped by how g1t works, Soon pages for every promise, and sudo for sales177 summary: "Turn features on per environment or per user, without a deploy.",
178 why: "Ship code dark and turn it on when ready, for some users first, at the edge, with no deploy.",
179 plans: ["Flags read at the edge by deployed apps", "Rollouts by percentage, user or environment", "Flags cleaned up by agents when fully on"],
180 today: { label: "Deployments", path: "deployments" },
181 },
182
183 // --- Security -------------------------------------------------------------
Agents get guardrails, run credentials, an audit log, a context hub, repository instructions and mentions; security upkeep; snake_case API184 // The overview, secret scanning and dependency upkeep are built: see
185 // routes/repo/security.tsx.
A menu shaped by how g1t works, Soon pages for every promise, and sudo for sales186 {
187 key: "code-scanning",
188 title: "Code scanning",
189 section: "Security",
190 summary: "Code scanned for vulnerabilities on every change.",
191 why: "Scanning on every pull request, with findings explained in the review and fixed by the author's agent.",
192 plans: ["Static analysis on every pull request", "Findings in the review, with a fix", "Baselines so only new findings block"],
193 },
194 {
195 key: "firewall",
196 title: "Firewall",
197 section: "Security",
198 summary: "Rules for who may reach the project's deployed apps.",
199 why: "Deployed apps run on Cloudflare. Rate limits, bot protection and IP rules, per app and environment.",
200 plans: ["Rate limits and bot protection", "IP and country rules", "Password-protected previews"],
201 today: { label: "Deployments", path: "deployments" },
202 },
203
204 // --- Observe ------------------------------------------------------------
205 {
206 key: "logs",
Observability gets its own page; tabs never overflow207 title: "Logs",
208 section: "Observability",
A menu shaped by how g1t works, Soon pages for every promise, and sudo for sales209 summary: "Requests, errors and CPU time of each deployment, and its logs.",
210 why: "Every deployed app's logs and numbers, by deployment, so a regression points at the change that caused it.",
211 plans: ["Live and searchable logs", "Requests, errors, latency and CPU by deployment", "Compare a preview with production"],
212 today: { label: "Deployments", path: "deployments" },
213 },
214 {
215 key: "errors",
Observability gets its own page; tabs never overflow216 title: "Errors",
217 section: "Observability",
A menu shaped by how g1t works, Soon pages for every promise, and sudo for sales218 summary: "Errors from the running app, each becoming an issue an agent can take.",
219 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.",
220 plans: ["Errors grouped with stack and request", "One click to an issue for an agent", "Incidents with a timeline and who was told"],
221 today: { label: "Issues", path: "issues" },
222 },
223 {
224 key: "uptime",
225 title: "Uptime",
Observability gets its own page; tabs never overflow226 section: "Observability",
A menu shaped by how g1t works, Soon pages for every promise, and sudo for sales227 summary: "Checks that the app answers, from around the world.",
228 why: "Know the app is down before your users tell you, and who was told.",
229 plans: ["Checks from many places", "Alerts by email and webhook", "A public status page"],
230 },
231 {
232 key: "analytics",
233 title: "Web analytics",
Observability gets its own page; tabs never overflow234 section: "Observability",
A menu shaped by how g1t works, Soon pages for every promise, and sudo for sales235 summary: "Who visits the deployed apps, without cookies.",
236 why: "Visits, pages and referrers for each app, private by design, from Cloudflare's own analytics.",
237 plans: ["Visits, pages, referrers and countries", "No cookies, no personal data", "Per deployment and per preview"],
238 },
239
240 // --- Insights -------------------------------------------------------------
241 {
242 key: "delivery",
243 title: "Delivery",
244 section: "Insights",
245 summary: "Lead time, deploy frequency, change failure rate and time to restore.",
246 why: "The four numbers that say how well a team ships, measured from what actually happened in g1t.",
247 plans: ["DORA metrics from merges and deployments", "Review and queue time", "Trends by week and by project"],
248 },
249 {
250 key: "costs",
251 title: "Costs",
252 section: "Insights",
253 summary: "What the project costs, by agent run, sandbox, build and app.",
254 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.",
255 plans: ["Cost by kind of work and by issue", "Cost per merged change", "Budgets per project"],
256 },
257 {
258 key: "impact",
259 title: "Agent impact",
260 section: "Insights",
261 summary: "How much of the work agents do, and how well.",
262 why: "The share of changes agents author, how often their work lands first time, and where people still step in.",
263 plans: ["Agents' share of merged changes", "First-time pass rate of checks and reviews", "Where people correct agents most"],
264 },
265];
266
267export function roadmapItem(key: string): RoadmapItem | undefined {
268 return ROADMAP.find((item) => item.key === key);
269}
270
271export function roadmapIn(section: RoadmapItem["section"]): RoadmapItem[] {
272 return ROADMAP.filter((item) => item.section === section);
273}