jmoran/forge-jay
1
0
Fork 0
forked from trevato-apps/forge
Code Issues 1 Pull requests Activity

feat/dev-ui #10

Closed
jmoran wants to merge 34 commits from feat/dev-ui into feat/build-graph
pull from: feat/dev-ui
merge into: jmoran:feat/build-graph
Conversation 1 Commits 34 Files changed 202 +9829 -6376
jmoran commented 2026-10-26 03:53:22 +00:00
Owner
Copy link

Stop abstracting things.

Stop abstracting things.
primitive.ts gives every issue, pull request, fork and deployment page
one shape: kind, title, number and state; primary actions and one
Actions menu; info sections that start open; and an Automation panel
for anything the forge does on its own. docs/WORDING.md states the
rules the pages are written to.
The issue page now uses primitiveLayout: kind, title, number, Open/Closed
state and an opened-by byline; Comment and Close issue/Reopen issue as
primary buttons; edit, assign, labels, dependency, milestone, seal,
private fix repository, copy link and origin in the Actions menu.
Details, Assignee, Labels, Milestone, Dependencies, Linked pull requests
and Participants are info sections with their forms. The crew and
autonomy are Automation panels; the studio's word appears only there,
as the inferred state.

The new-issue page says New issue and Create issue, offers labels and an
assignee to writers, and a separate checkbox that assigns the crew's
builder. A comment can close the issue with a reason (Close with
comment). The timeline names assignments and dependency changes.
Rows read "opened <time> by <author>", the assignee, the comment count
and the update time. Filter chips name the field (assignee:, author:,
title contains:). The compose button says New issue; the signed-out
button says Sign in to create an issue; outside reports read as problem
reports.
One header for every tab: kind, title, number, state, and a byline of
facts. Merge pull request (with the merge method) shows only where
mergePull would take it, else the one reason it cannot; Close and Reopen
beside it; every other action in the Actions menu. The rail lists
details, branches, checks, reviews, deployments, labels, assignee,
linked issues and participants. The crew, autonomy and the inferred
state move into Automation panels.

Tabs: Conversation, Commits (new route), Files changed. Edit title and
description is reachable from the menu. Flashes for merge, revert, hold
and release say what failed and what to do. Tests follow the wording.
Deployments carries the preview's state badge, why it sleeps, and Open,
Redeploy or Wake preview. The preview screenshots return to the
Conversation tab. Agent runs are read in one query, so the page costs no
more as a pull's runs grow.
The Forks page is a primitive page: a table of forks (name, created,
ahead and behind the parent's default branch, last push, visibility),
the lineage, and the Fork form labelled "Name of the new fork". A
fork's card says "Fork of X. N commits behind, M ahead. Conflicting
files: ..." and offers "Merge upstream main into main" and "Open pull
request to X"; the crew's merge is an Automation panel inside it.
The primitive layout's rules and the table rules join the stylesheet.
The app's page is a Deployments table: one row per environment
(production, demo, each pull preview, each build preview) with commit,
branch or pin, the runtime's state, URL, started and last deploy run,
and each environment's actions in its row's menu (Open, Redeploy,
Stop, Start, Clear demo, View log, Open terminal). Redeploy production
is the primary; app settings, environment variables and access are in
Actions. The rail lists the app record, the terminal, forge.json, the
contract and seven days of usage; automatic deploys, the crew's runs in
flight and screenshots are Automation panels. POST /app/demo/clear
clears the demo from the web.

The run list is a table (kind, trigger, commit, environment, state,
duration, cost, actor, created) filtered by ?kind= and ?state=, with
Cancel run and Retry run in each row's menu. The run page is a
primitive page with the same facts, Cancel run / Retry run, and the
log. POST /runs/:id/retry queues an agent run's task again or
redeploys a deploy run's environment.
# Conflicts:
#	test/apps-idle.test.ts
#	test/studio.test.ts
# Conflicts:
#	src/web/pages/following.ts
#	src/web/pages/search.ts
#	src/web/studio/actions.ts
#	test/apps-idle.test.ts
#	test/contents-api.test.ts
#	test/following.test.ts
#	test/forks.test.ts
#	test/holds.test.ts
#	test/studio-words.test.ts
#	test/studio.test.ts
#	test/web-ui.test.ts
The Tree look now shows which pins carry on and which stop.

- each repository's next pin sits on the same row, left to right
- a thick accent line marks history that reaches a main branch
- pins no main branch holds, here or downstream, are faded
- the side panel lists what each pin was carried into
- the graph scrolls at full size instead of shrinking to fit
A pin can now name the cartridge it releases, stored in git on the pin itself.

- Cart name, version, producer, page, shelf switch and cover ride as trailers on the pin's tag.
- Changing them rewrites the tag for the same commit, keeping who pinned it, when, and the note.
- An uploaded cover is kept in git as a picture the pin names.
A cart's page is now captured from its build and kept, so it plays without a running preview.

- Capturing starts the build's preview when needed, waits for it, and saves the page and a picture of it.
- Captures sit in the forge's data folder by repo, commit and page, and are never overwritten.
- What a capture under way or a failed one looks like is kept in memory for the panel.
A pinned build now has a cartridge panel beside the build graph, as in mockup F.

- It shows the cover, cart name, version, producer, page and an "On the shelf" switch.
- Writers save the facts, flip the switch and upload a cover. Readers see the facts.
- A cart with no capture yet starts one. Download takes the capture when there is one.
- A cover nobody uploaded is the page's picture, drawn in the house cover style.
A public Arcade page now lists every cart switched on the shelf, from any repository.

- It is the browser arcade as it was: the chunky carousel, the console and the jbox boot tag.
- It answers at arcade on the apps domain, its own address, so carts keep their saves and never run as the forge.
- Carts with the same name are one cartridge, and each shelved pin is one of its builds.
- The forge's top bar links to it as Arcade. No app or account may take the name.
The Arcade's "Export snapshot" link now downloads the whole shelf as one HTML file.

- Every shelved cart, cover and picture goes inside the page, so it plays from disk.
- The file is browser-arcade-<date>.html, as before.
- Its one top line reads "JBOX • snapshot <yyyymmdd> | This is an HTML file that doesn't receive updates".
Pinning is now the release step: a new pin becomes a cartridge with its page saved.

- The pin form ticks "Release it as a cartridge" by default. The Arcade shelf stays off until someone turns it on.
- A branch named iter-N offers iter-N as its label, and a fork's first pin offers iter-1.
- A fork of an app runs as an app too, so its pins can play.
- The API releases a cartridge when asked with "cart": true.
An operator can now bring in cart files that were built elsewhere.

- Each entry pins its commit if needed, puts the cart facts and cover on the pin, and stores the file as its capture.
- It is for games whose offline file comes from their own build, like Krazy Karts, and for moving today's shelf in.
- Run it with bun scripts/import-carts.ts on the forge's data folder. A capture already there is kept.
The picture a cart's cover is drawn from is now taken wide, as games draw themselves.

- A square window left black bars above and below a letterboxed game.
- The cover still crops the middle square.
The shelf now opens on the cartridge pinned first, rather than sorting by day and then by name.

- Carts pinned the same day no longer fall into alphabetical order.
A cartridge on the shelf now has a Play button in its panel.

- Play opens the Arcade on that cart, so it boots through the jbox tag.
- The note about write access no longer shows beside a cart that can be downloaded.
Pins on the build graph can now carry an icon and a note, for showing a build to a given audience.

- The icon sits inside the pin's node. The note's first line sits under it.
- Writers set both in the pin's panel, under "On this graph". Readers see them.
- They are kept beside the forge's data, not in git, and never change the pin.
jmoran commented 2026-11-02 22:43:06 +00:00
Author
Owner
Copy link

these changes were delivered in #11

these changes were delivered in #11
jmoran closed this pull request 2026-11-02 22:43:06 +00:00

Pull request closed

Please reopen this pull request to perform a merge.
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
jmoran/forge-jay!10
No description provided.