orizu 0.5.37 → 0.5.39

package/vendor/skills/orizu/references/building-apps.md

@@ -1608,3 +1608,27 @@ Before `orizu apps create`:
 - [ ] `?` shortcut overlay or visible cheat sheet
 - [ ] Smoke test passes (`node scripts/test-app.mjs ...`)
 - [ ] Local preview renders and screenshot is inspected against the user's intended workflow (`orizu apps preview ... --screenshot preview.png`)
+
+---
+
+## Publishing from a hosted session
+
+In a hosted session, `orizu apps create` and `orizu apps update` publish through git. Pass `--file`, `--input-schema` and `--output-schema` as usual; the command then:
+
+1. Copies the three files into `projects/<project-slug>/apps/<app-id>/` in the workspace as `App.tsx`, `input.schema.json` and `output.schema.json`, commits only App.tsx, input.schema.json, and output.schema.json, and pushes the session copy.
+2. Merges the session into the team copy, then records the version. It prints `Merged into the team copy: <sha>` or `Already in the team copy: <sha>`.
+
+Edit an existing app in its folder and pass those files to `apps update`. A new app can live anywhere until `apps create` places it.
+
+The merge includes all earlier committed work on the session branch, including files outside the app folder. Review that work before publishing. Unrelated uncommitted work stays local. A conflict may name files outside the app folder; resolve and commit those files too.
+
+When a hosted `apps create` or `apps update` stops after its folder is known, its error prints `App ID`, `Folder`, and a full `Retry` command. Keep that ID and folder. After all three app files have been written, the retry uses safe canonical files, preserving committed conflict resolutions. If the attempt stops before all three files are written, the retry keeps the original input paths. Both retries preserve the selected server. After following the error's instructions, run the printed retry command; create keeps its original `--id`, and update keeps its `--app`. This also applies when the push is rejected, the API refuses the create, or the merge is still running. The files and commits already made stay in the workspace; a refused push has not sent them to the server.
+
+An explicit publish refusal before recording means no app version was recorded. Act on its message, then use the printed retry command. If transport fails or the response cannot be read, the outcome is uncertain: check the retained app ID before retrying.
+
+- **Conflict** (names the files): run the full printed `Recovery` command. It checks whether the workspace is shallow, fetches missing history from origin if needed, then pulls the team copy with an explicit merge strategy. If ancestry preparation fails, stop and repair origin before retrying; the team pull must not run. Resolve those files and commit. For `apps create`, use the printed retry command with its original `--id`, so the app keeps its folder.
+- **Session copy has commits this workspace does not**: run `git pull --no-rebase --no-edit`, then retry. For `apps create`, keep the printed `--id`.
+- **Still merging, other publishes landed first, or failed**: retry. For `apps create`, use the printed retry command with its original `--id`; for `apps update`, use its printed retry command.
+- **Refused** (the session ended or the team paused agents): stop and tell the user.
+
+Outside a hosted session the command records the version only, and prints a note that it is not in the team repository yet.

package/vendor/skills/orizu/references/cli-reference.md

@@ -192,10 +192,17 @@ Profile, never a version, and exposes no fallback or affected-Profile list.
 `default move` repoints
 Default to the named Profile without moving Production; if that Profile is
 unpromoted, bare resolution refuses with `instruction_set_profile_not_promoted`.
-`shape add` and `shape remove` create a new complete version for every profile;
-they never move Default or a Production label. The set does not resolve for affected model
-configs until those pointers move to the new shape-change profile versions; the
-text CLI prints the required follow-up commands.
+`shape add` and `shape remove` work only until the first promotion of any
+profile. They create a new complete unpromoted version for every profile and
+never move Default or a Production label. First promotion permanently freezes
+the shape; changing component names after publication requires a new instruction
+set, even after archiving or removing production pointers. Every set that
+existed when this rule shipped is already frozen, including drafts, so a 409
+`Instruction set shape is permanently frozen` on an existing set means: create a
+new instruction set. If sync or a run refuses with
+`instruction_set_production_shape_mismatch`, the Production version predates the
+freeze and disagrees with the set's components; hand off creating and promoting
+a compatible version to a human. Exact `@vN` sync still works.
 
 The manifest is a JSON object with `name`, optional unversioned `description`,
 ordered `shape`, and `components`. The description belongs to the instruction
@@ -309,6 +316,8 @@ orizu apps update \
   --output-schema ./schemas/output.json
 ```
 
+In a hosted session both commands commit the app into `projects/<project-slug>/apps/<app-id>/` and merge it into the team copy before recording it; `apps create --id <app-id>` reruns a create that stopped and keeps its folder. See [building-apps.md](building-apps.md#publishing-from-a-hosted-session).
+
 Link dataset:
 
 ```bash

package/vendor/skills/orizu/references/optimization-reports.md

@@ -52,7 +52,7 @@ Second, before pushing, require the target profile's `model_config_settings_vers
 
 Once a supported surface can prove equality, the agent may copy the selected value exactly into the complete manifest while preserving every other override and pin, then use the runner-pinned push above on the local surface. Moving exactly one verified serving pointer remains human-only. An existing Production Profile would be promoted by the human and recover with `orizu instructions profiles rollback <set> --project <team/project> --model-config <identity> --to <previous-production-version-number>`. A human managing Default would first confirm the target Profile has a reviewed Production Version, move Default to that Profile identity, and recover by moving the prior Default Profile identity back. If a change must affect only one identity, a curator establishes a dedicated Profile only when none exists and confirms a recovery target; an existing unpromoted Profile makes `profiles new` reject and remains unusable until promoted. These are blocked flow shapes, not permission to bypass the settings proof.
 
-If the blocked set-of-one run should instead become a profile-recorded optimization, change the instruction-set shape to more than one real, separately optimized component, validate the new multi-component manifest and dataset contract, and only then rerun. Repeating the same one-component shape remains a prompt-version run. If that material redesign is not warranted, keep the current run at **Gather more evidence**.
+If the blocked set-of-one run should instead become a profile-recorded optimization, give it more than one real, separately optimized component, validate the new multi-component manifest and dataset contract, and only then rerun. Shape edits work only until a set's first promotion; a published or rollout-frozen set needs a new instruction set with the new shape. Repeating the same one-component shape remains a prompt-version run. If that material redesign is not warranted, keep the current run at **Gather more evidence**.
 
 Pre-promotion Final-held-out confirmation is unsupported for a plain-prompt run today: the selected prompt version does not exist until its live pointer move. The report must present validation-only evidence, mark Final-held-out as **not obtainable before promotion**, and never describe Final-held-out proof as completed. If policy requires Final-held-out evidence before production, recommend **Gather more evidence** and do not run the promotion command. If a human explicitly accepts live-first verification, phrase the ship recommendation as a **post-promotion verification plan**: name the watch window, failure threshold, and confirmed rollback path before promotion. The current CLI has no plain-prompt rollback command, so do not invent one; if no external/manual rollback path is confirmed, recommend **Gather more evidence**. A set-of-one run also stops today when complete local runner evidence is unavailable and, even when that runner is known, because run-versus-target settings equality cannot be proven through the supported CLI.
 

package/vendor/skills/orizu/references/primer.md

@@ -125,6 +125,7 @@ Two artifacts: an **app** (custom labeler UI) and a **task** (the labeling round
 
 ```bash
 # 1. Create the labeler app, bound to the dataset
+#    (in a hosted session it is committed and merged into the team copy first; see building-apps.md)
 orizu apps create \
   --project <teamSlug>/<projectSlug> \
   --name "Support QA Labeler" \

package/vendor/skills/orizu/references/prompt-control-plane.md

@@ -67,17 +67,21 @@ display name. Archiving changes list visibility only, so archived sets still res
 and sync; use `--status archived` or `--status all` to find them before
 restoring.
 
-Shape changes create unpromoted profile heads but leave the default and
-production pointers in place. The instruction set does not resolve for affected
-model configs until those pointers move to their new shape-change versions; use
-the follow-up commands printed by the text CLI.
+Shape add/remove works only until the first promotion of any profile. Draft
+shape changes create unpromoted profile heads and leave Default in place. First
+promotion permanently freezes component names; changing a published shape
+requires a new instruction set, even after archiving or removing production
+pointers. Sets that existed when this rule shipped are frozen too, including
+drafts. `instruction_set_production_shape_mismatch` means a pre-freeze Production
+version disagrees with the set's components; a human must promote a compatible
+version, and exact `@vN` sync still works meanwhile.
 
 `default show` reports the Default Profile and the Version its Production
 currently names, or `null` when that Profile is unpromoted. `default move`
 targets a Profile by model-config identity, never a Version, and does not move
 Production. Moving Default to an unpromoted Profile makes bare resolution refuse
 with `instruction_set_profile_not_promoted`; no other Profile falls back to it.
-Shape changes create a new `shape_change` Version for every Profile; they do not
+Before first promotion, shape changes create a new `shape_change` Version for every Profile; they do not
 repoint Default or any Production label.
 
 Sync an offline runner directory with `orizu instructions sync planner