Config files open as a form: JSON edited through a clean, typed UI that commits or proposes #7392

A .json file now opens as a form. Writers commit through it. Everyone else (readers, agents, and writers blocked by a protected branch) gets a pull with that commit. The new test file and the related suites pass, and the type check, design lint and README cap test are clean.

What a person sees

• Blob page: a JSON file's Rendered view shows its values as read-only fields, with an Edit as form button. Rendered | Source | Raw | Download are all still there. A file that isn't valid JSON shows the parse error with its line and column, with the bad line marked in the text below.
• Editor (GET /:owner/:name/config/:ref/*path):

- Without a schema, each value's type picks the field: text, number, checkbox, null, a fieldset for a nested object, chips for an array of scalars, and cards for an array of objects. Cards can be added, removed and moved up or down. - With a schema, an enum becomes a select and description becomes help text. required, minimum, maximum and pattern become input attributes, so the browser checks them as you type. - The schema is looked for in this order: $schema in the file (if it's a path), a sibling <name>.schema.json, then .forge/schemas.json.

• Save: Review shows a diff and a commit message first.

- A writer gets one commit on the branch. - Anyone else gets a new branch and a pull. A reader's branch goes on their fork, which is made if they don't have one. - The file keeps its key order, indent, line endings, final newline and number spelling. - A save that changes nothing writes nothing. - If the file changed on the branch after it was opened, the save stops and asks for another review.

• Everything works as plain form posts with no JavaScript. Each card button submits the form and the page comes back with the change applied. "Progressively better" is only the browser's own inline checks; I added no script.

What to look at

• src/web/render/json-doc.ts is a small JSON parser and writer. I wrote it because JSON.parse reorders integer-like keys, drops number spelling (1.0 becomes 1), and gives no line number on errors.
• src/web/render/json-schema.ts handles the schema subset and the lookup. The server never runs a regular expression from the repository; pattern is only checked in the browser. The glob map is capped in size.
• src/web/render/config-form.ts draws the fields and reads them back. It also applies the card buttons (add, remove, up, down).
• src/web/pages/config.ts holds both routes. A private repository is a 404 before the form body is even read.
• src/actions/propose_edit.ts handles the branch-and-pull for anyone who doesn't commit directly. Two limits:

- A stale fork proposes against its own older copy of the branch. - Only members can fork, so a guest is told to ask the forge's admin.

• src/web/pages/repo.ts changed by one line: it now calls rendererFor(kind, path) so only .json files draw as a form, and YAML and TOML keep their source view.

Choices and limits

• Schema: the blob page's read-only view doesn't use it, because renderers there can't read other files. The editor does.
• Agents: they edit files through the existing MCP file tools. This form adds no new MCP tool.
• Tests: test/config-form.test.ts has no test of an agent being sent to Propose. That rule is in commitsDirectly.
• Escapes: when a file is saved with changes, any \uXXXX escapes in its strings are written back as plain characters.
• Size: files over 256 KB or with more than 2,000 values stay in the source view.
• Styling: five classes added at the end of style/content.ts, named in docs/design/areas/config.md. How-to is in docs/features/config-form.md, linked from the README.

Try it: open any .json file in a public repository on the preview, click Edit as form, change a value, then Review changes and Commit. Signed in as someone else, the same steps end in Propose change and a pull from their fork.

🤖 Generated with Claude Code

Closes #7336

A .json file now opens as a form. Writers commit through it. Everyone else (readers, agents, and writers blocked by a protected branch) gets a pull with that commit. The new test file and the related suites pass, and the type check, design lint and README cap test are clean.

What a person sees

• Blob page: a JSON file's Rendered view shows its values as read-only fields, with an Edit as form button. Rendered | Source | Raw | Download are all still there. A file that isn't valid JSON shows the parse error with its line and column, with the bad line marked in the text below.
• Editor (GET /:owner/:name/config/:ref/*path):

- Without a schema, each value's type picks the field: text, number, checkbox, null, a fieldset for a nested object, chips for an array of scalars, and cards for an array of objects. Cards can be added, removed and moved up or down. - With a schema, an enum becomes a select and description becomes help text. required, minimum, maximum and pattern become input attributes, so the browser checks them as you type. - The schema is looked for in this order: $schema in the file (if it's a path), a sibling <name>.schema.json, then .forge/schemas.json.

• Save: Review shows a diff and a commit message first.

- A writer gets one commit on the branch. - Anyone else gets a new branch and a pull. A reader's branch goes on their fork, which is made if they don't have one. - The file keeps its key order, indent, line endings, final newline and number spelling. - A save that changes nothing writes nothing. - If the file changed on the branch after it was opened, the save stops and asks for another review.

• Everything works as plain form posts with no JavaScript. Each card button submits the form and the page comes back with the change applied. "Progressively better" is only the browser's own inline checks; I added no script.

What to look at

• src/web/render/json-doc.ts is a small JSON parser and writer. I wrote it because JSON.parse reorders integer-like keys, drops number spelling (1.0 becomes 1), and gives no line number on errors.
• src/web/render/json-schema.ts handles the schema subset and the lookup. The server never runs a regular expression from the repository; pattern is only checked in the browser. The glob map is capped in size.
• src/web/render/config-form.ts draws the fields and reads them back. It also applies the card buttons (add, remove, up, down).
• src/web/pages/config.ts holds both routes. A private repository is a 404 before the form body is even read.
• src/actions/propose_edit.ts handles the branch-and-pull for anyone who doesn't commit directly. Two limits:

- A stale fork proposes against its own older copy of the branch. - Only members can fork, so a guest is told to ask the forge's admin.

• src/web/pages/repo.ts changed by one line: it now calls rendererFor(kind, path) so only .json files draw as a form, and YAML and TOML keep their source view.

Choices and limits

• Schema: the blob page's read-only view doesn't use it, because renderers there can't read other files. The editor does.
• Agents: they edit files through the existing MCP file tools. This form adds no new MCP tool.
• Tests: test/config-form.test.ts has no test of an agent being sent to Propose. That rule is in commitsDirectly.
• Escapes: when a file is saved with changes, any \uXXXX escapes in its strings are written back as plain characters.
• Size: files over 256 KB or with more than 2,000 values stay in the source view.
• Styling: five classes added at the end of style/content.ts, named in docs/design/areas/config.md. How-to is in docs/features/config-form.md, linked from the README.

Try it: open any .json file in a public repository on the preview, click Edit as form, change a value, then Review changes and Commit. Signed in as someone else, the same steps end in Propose change and a pull from their fork.

🤖 Generated with Claude Code

A .json file in a repository now opens as a form. A writer commits through it; a reader, an agent, or a writer facing a protected default branch proposes the change as a pull. This round fixes all five review points. The new and covering tests pass (277 across 12 files, including the five cross files), along with bun x tsc --noEmit and the design lint.

1. ReDoS in globMatches, fixed. Globs from .forge/schemas.json used to be compiled into a RegExp, and a run of a backtracked exponentially. They are now matched path segment by path segment, with the standard one-restart wildcard algorithm, so the time is bounded by glob length × path length. No regular expression is built from repository text any more, and the wrong "linear" comment is gone. The reviewer's glob ("a" × 12 + "b") used to take 1.7 s against a 34-character path. The new test runs a longer one ("**a" × 66 + "b") against a 65-character path and gets false in under a millisecond; its 5-second bound is only a hang guard.

2. The form uses the shared components.

• field() in ui.ts now also draws a select, a checkbox, number bounds (min, max, step), a screen-reader-only label, and a control after the input (a chip's Remove button).
• btn() has a formnovalidate option.
• Both are added to the components table in docs/design/sections/5-components.md.
• Every scalar field and every button in the form is drawn by those two functions; the raw() buttons are gone.
• The hidden aria-hidden default submit button is removed. Review is now the first submit button in the form, so Enter in any field reviews the change.

3. The terminal can propose and check schemas.

• A signed-in reader of a forge repository can now edit in the workspace (e, then c). The commit dialog opens as "Propose a change" and calls proposeEdit, so the change lands on a branch of their fork with a pull back. Mirrors still propose through their origin, as before.
• Every commit and proposal from the workspace first runs schemaRefusal, the same validate() the web form uses. A file that breaks its schema is refused in the dialog with the field and schema named, and nothing is written.
• The refusal wording (proposeEditText) now lives in actions/propose_edit.ts, so the page and the terminal say the same thing.
• Covered by test/tui-propose-edit.test.ts. The README and docs/features/config-form.md say how to do it from the terminal.

4. Tests for the rules that had none:

• An agent with write access proposes on a branch of the repository itself, while a person on the same team commits directly. The agent gets write access by being on an org write team, because being on a repository's crew does not count as write access to canWrite.
• A non-admin writer on a protected default branch proposes inside the repository, and no fork is made.
• A guest and an unconfirmed account each get the page's exact refusal words.
• A signed-in user who cannot read a private repository gets 404 on the POST.
• Add and remove buttons posted as a real form round-trip through configSubmit, keep the other typed values, and save nothing.

I checked the two commitsDirectly tests by deleting each condition in turn: the matching test fails both times.

5. Help text is read with its field. aria-describedby now points at both the hint and the error, through field().

I disagreed with nothing in the review.

🤖 Generated with Claude Code

A .json file in a repository opens as a form. A writer commits through it; anyone else proposes the change as a pull. The terminal does the same: a reader proposes from their fork, and a commit that breaks a JSON file's schema is refused first.

The failing check: my field() change put a stray space inside every ordinary label (<label for="…" >). The origins page test (test/web-origins.test.ts) matches that markup exactly, so it broke. The fix in src/web/ui.ts draws ordinary labels byte-for-byte as they were; only a screen-reader-only label (a chip's) takes the other branch. The test itself was right and is unchanged. The fix is pushed.

What the pull does:

• Reading: a JSON file's Rendered view shows its values as read-only fields, with Edit as form next to them. If the file isn't valid JSON, the page shows the error with its line and column.
• Editing (/:owner/:name/config/:ref/*path): fields take their type from the file's schema when one is found, or from the values. Cards and chips can be added, removed and moved with plain form posts, so no JavaScript is needed.
• Saving: Review shows a diff first.

- A writer commits one commit to the branch. - A reader, an agent, or a non-admin writer on a protected default branch gets Propose change (actions/propose_edit.ts). The commit goes on a new branch with a pull: on the reader's fork, or in the repository itself for a writer. - The file keeps its key order and indent, and a save that changes nothing writes nothing.

• Terminal: in the workspace, a reader presses e to edit and c to propose. Every commit or proposal from there is checked against the JSON file's schema first, with the same rules the web form uses.
• Shared code: a schema glob is matched segment by segment, which can't stall the server the way the old regular expression could. The form is drawn with the shared field() and btn() helpers, which gained select, checkbox, number bounds and formnovalidate.

What to look at:

• src/web/render/{json-doc,json-schema,config-form,config}.ts
• src/web/pages/config.ts
• src/actions/propose_edit.ts
• the propose path and schema check in src/tui/screens/workspace.ts
• the field() additions in src/web/ui.ts

Tests:

• bun x tsc --noEmit is clean.
• The origins test file, test/config-form.test.ts and test/tui-propose-edit.test.ts pass.
• So do the other tests that check label markup, a set of form-page and security suites, and the five cross files.

How to try it: open a .json file in a public repository, click Edit as form, change a value, then Review changes and Commit. Signed in as someone without write access, the same steps end in Propose change and a pull from their fork.

🤖 Generated with Claude Code

A .json file in a repository now opens as a form. A writer commits through it, and anyone else proposes the change as a pull. The terminal can do both: a reader proposes from their fork, and a commit that breaks a JSON file's schema is refused before it is written.

Merging main: main now has its own rendererFor(path, blob) in src/web/render/renderers.ts. It works out the file's kind, applies the size cap, and draws large audio and video straight from the media route. The merge keeps main's version whole. The one thing this pull adds to it is the rule that a config file is drawn as a form only when it is JSON; YAML, TOML and the rest keep their source view. src/web/pages/repo.ts now just calls main's rendererFor, as it does on main, so this pull no longer changes that file.

What the pull does:

• Reading: the blob page's Rendered view shows a JSON file's values as read-only fields, with an Edit as form button. A file that isn't valid JSON shows the parse error and its line.
• Editing: /:owner/:name/config/:ref/*path types each field from the file's schema when one is found, otherwise from the values. Cards and chips are added, removed and moved with plain form posts, so no JavaScript is needed.
• Saving: a diff review comes first.

- A writer gets one commit on the branch. - A reader, an agent, or a non-admin writer on a protected default branch proposes instead, through actions/propose_edit.ts. The change goes on a new branch with a pull: on the reader's fork, or in the repository itself for a writer. - Key order and indent are kept, and a save that changes nothing writes nothing.

• Terminal: in the workspace a reader proposes with e then c. Every commit or proposal there is checked against the JSON file's schema first.

After the merge, bun x tsc --noEmit and the design lint are clean. 336 tests across 14 files pass, including the new render-media tests from main and the five cross files.

Try it: open a .json file in a public repository, click Edit as form, change a value, then Review changes and Commit. Signed in as someone without write access, the same steps end in Propose change and a pull from their fork.

🤖 Generated with Claude Code

A .json file in a repository opens as a form. A writer commits through it, and anyone else proposes the change as a pull. In the terminal, a reader can propose too, and a commit that breaks a JSON file's schema is refused before it is written.

The merge. main changed rendererFor in src/web/render/renderers.ts. It now takes the map of renderers as an argument (defaulting to RENDERERS), and decides what an oversized file is from its first bytes when the page has them. I kept all of that. The config renderer is now an ordinary entry in RENDERERS, beside markdown, audio and video. rendererFor still adds one rule: a config file is drawn as a form only when it is JSON, and YAML, TOML and the rest keep their source view.

After the merge, bun x tsc --noEmit and the design lint are clean. 336 tests across 15 files pass, including main's render-media tests and the five cross files.

What the pull does:

• Reading: a JSON file's Rendered view shows its values as read-only fields, with an Edit as form button. A file that isn't valid JSON shows the parse error with its line.
• Editing: the form at /:owner/:name/config/:ref/*path takes each field's type from the file's schema when one is found, otherwise from the values. Cards and chips are added, removed and moved with plain form posts, so it works without JavaScript.
• Saving: a diff review comes first.

- A writer makes one commit on the branch. - A reader, an agent, or a non-admin writer on a protected default branch proposes instead (actions/propose_edit.ts). The change goes on a new branch with a pull: on the reader's fork, or in the repository itself for a writer. - Key order and indent are kept, and a save that changes nothing writes nothing.

• Terminal: a reader proposes from the workspace with e then c. Every commit or proposal there is checked against the JSON file's schema first.

Try it: open a .json file in a public repository, click Edit as form, change a value, then Review changes and Commit. Signed in as someone without write access, the same steps end in Propose change and a pull from their fork.

🤖 Generated with Claude Code

Sentinel re-approved at cf036707 and made no new asks, so I changed nothing and there is nothing to push. This reply is the pull description.

What the pull does: Config files (.json that isFormJson(path) accepts) open as a typed form. A person can commit the edit or propose it. .jsonc, YAML and TOML keep their source view. A JSON file over the read ceiling falls back to source. Since the merge of main, config is an ordinary entry in RENDERERS in src/web/render/renderers.ts.

What I checked: I ran nothing new in this turn. I'm relying on the checks Sentinel reported at cf036707: tsc clean, design-lint clean, and 44/44 passing across config-form, tui-propose-edit and render-media.

What I chose not to do: I added no features beyond the issue and made no further refactors.

How to try it: Open a repository's .json config file from the feed and it renders as a form. The preview holds no repositories, so /config/… returns 404 there. The end-to-end tests stand in for a click-through.

I disagree with nothing in the review.

I merged main into the branch and pushed it. It had two conflicts, and I resolved both by keeping both sides.

• src/web/render/renderers.ts: I kept both imports, config/isFormJson from this branch and image from main. The map and the JSON-form check now use both.
• src/tui/screens/workspace.ts: main added the table status and table-problem text to the status line, and this branch already had the " · proposes from your fork" suffix. The status line now has both.

bun x tsc --noEmit printed no errors. I ran config-form, render-kinds, render-image and tui-workspace, and all 66 tests pass.

I did not run the rest of the suite here. scripts/fast.ts said the diff was too broad to name tests, 1106 of 1622 files at an expected 95 minutes, so the forge's check on this push covers the rest.

I merged main into this branch and pushed it. The merge now applies cleanly.

The only conflict was in src/web/render/renderers.ts. main added the CSV renderer's import (csv), and this branch added the config-form renderer's (config, isFormJson). I kept both imports, and the renderer table lists csv and config side by side.

• Checks run: tsc --noEmit and scripts/design-lint.ts came back clean. The 7 render test files pass (82 tests).
• Not finished: the scripts/fast.ts run for the diff timed out at 120 seconds and was moved to the background. I never read its result, so I can't say whether the wider set passes. The forge's own check on this push will run the full suite.