Creating an app ends with a flash message on the repository page. The app itself — production coming up, the URL it will answer at, the first issue and who has it — is a click away, on a page the person was never sent to.
newAppSubmit finishes with flashTo(ctx, repoBase(repo), { message: … }) (src/web/pages/apps.ts:462). The message is already the right sentence: name is starting at url. agent was picked for #1 — …. It is only pointed at the wrong page. Two hundred lines below, the same file already knows better: redeploy and stop both flash to ${repoBase(repo)}/app (:793, :826).
This replaces #13, which asked for the redirect and a live log tail at once, could not land as one change, and whose pull went stale. It is the first half only, and it is small: the live tail is #88, which waits on this.
Acceptance
[ ] POST /apps/new redirects to the app's page — ${repoBase(repo)}/app, named explicitly so it is right in either mode — carrying the same sentence it flashes today.
[ ] That page server-renders, in the first paint: production's state and the URL it will answer at, the first issue and who has it, and the run that is working on it. The app's studio page already draws all three; this issue adds nothing to it.
[ ] A reader who cannot see the app gets the forge's not-found, unchanged.
[ ] Nothing else about creation changes: the same repository, the same scaffold, the same first issue, the same crew pick.
[ ] A test in test/apps.test.ts follows the redirect and finds, on the page it lands on, the app's name, the URL and the first issue's number. It fails on today's code.
[ ] bun test green.
Files I expect to change
src/web/pages/apps.ts (the one redirect target), test/apps.test.ts.
Risks
Scope. If you find yourself in src/web/live.ts, the change has become #88. This is a redirect and the test that proves where it lands.
The app page must be worth landing on the moment it is reached: a brand-new app has no deploy, no preview and a run that has barely started, so check the empty states read as coming up, not as nothing here. If one of them reads wrong, fix that line here — it is the first thing a new person sees.
Creating an app ends with a flash message on the repository page. The app itself — production coming up, the URL it will answer at, the first issue and who has it — is a click away, on a page the person was never sent to.
newAppSubmitfinishes withflashTo(ctx, repoBase(repo), { message: … })(src/web/pages/apps.ts:462). The message is already the right sentence:nameis starting aturl.agentwas picked for #1 — …. It is only pointed at the wrong page. Two hundred lines below, the same file already knows better: redeploy and stop both flash to${repoBase(repo)}/app(:793,:826).This replaces #13, which asked for the redirect and a live log tail at once, could not land as one change, and whose pull went stale. It is the first half only, and it is small: the live tail is #88, which waits on this.
Acceptance
POST /apps/newredirects to the app's page —${repoBase(repo)}/app, named explicitly so it is right in either mode — carrying the same sentence it flashes today.test/apps.test.tsfollows the redirect and finds, on the page it lands on, the app's name, the URL and the first issue's number. It fails on today's code.bun testgreen.Files I expect to change
src/web/pages/apps.ts(the one redirect target),test/apps.test.ts.Risks
src/web/live.ts, the change has become #88. This is a redirect and the test that proves where it lands.Suggested: Scout.