gopherium/gophenberg

The theme kit release should refuse to publish a kit version that no released Gophenberg serves yet. Current state: the kit publish workflow checks only that the astro@ tag matches the package version. A server runs a theme only when it lists the theme's exact kit patch, and a fresh install picks up a new patch through its caret range. So a kit that reaches npm before any released server lists it breaks every theme rebuilt on it, and a pinned theme stops the server from starting. Today the order is kept by hand. Proposal: before npm publish, look through the released v* tags and stop unless one of them lists the kit version in internal/themehost/kit.go. Put the check in a Makefile target with a test, as make bump-kit has, and call it from the workflow. Trigger: the 0.15.1 kit release, where a server patch release had to ship first.

An import with an unknown field kind or page kind should explain the problem in the reader's language. Current state: with the admin in Spanish, open Field Groups, choose Import definitions and pick a file with a field of kind "sonnet". The dialog shows "content: invalid field kind" in English. A type with page kind "gallery" shows "content: invalid page kind" the same way. A Spanish message exists, but the server never sends the value and the allowed list it needs. An unknown status is bare too, though only a direct API call can send one. Proposal: field_kind_unknown, page_kind_unknown and status_unknown carry the refused value and the allowed values, as locale_unknown already does. A test checks each message fills. Trigger: a mutation test run showed these messages never fill.

A new field group should start on a real content type, or the form should say why it cannot yet. Current state: Open Field Groups while the content types are still loading, or after they fail to load. Press Add New Group, type a title and press Create. The form closes and a red notice says "The rule on content_type names nothing to match." The admin never saw a rule, so they cannot fix it. The form sent a content_type rule with an empty value, and the server refused it. Proposal: Keep Create disabled until the content types have loaded. If they fail to load, say so inside the form. Trigger: A mutation test run, confirmed by tests that stall or fail the content types read.

The import screen should always show and apply the definitions file the admin picked last. Current state: An admin opens Import definitions and picks a file. Before its plan shows, they pick a second file. The second plan shows first. Then the first file's plan replaces it. Clicking Apply sends the first file to the site. The admin thinks the second file landed. Proposal: Only the latest pick may set the plan and the file to apply. A late answer for an earlier pick is dropped. Moving the success and error handlers from useMutation onto read.mutate does this. A test makes the first of two picks answer late and checks the second plan shows and gets applied. Trigger: A mutation test run, confirmed by a probe test.

Changes an author makes while a save runs should never vanish. Current state: Open a post, type an excerpt and click Save draft. While the editor still says Saving, add more words. When the save answers, the excerpt goes back to the saved words. Save draft greys out, so nothing looks unsaved. A parent page, slug, status or custom field changed meanwhile is lost too. Title and content edits survive. Proposal: useEditorBuffer should take a value from the save answer only when the author left it alone during the save. A slug the server changed still shows. Add tests that edit the excerpt and parent while a save is held. Trigger: a mutation test run, where removing the calls that copy back the excerpt and parent failed no test.