@hitch42/applet 0.1.0-beta.10 → 0.1.0-beta.11

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@hitch42/applet",
-  "version": "0.1.0-beta.10",
+  "version": "0.1.0-beta.11",
   "license": "MIT",
   "bin": {
     "applet": "./dist/applet.js"
@@ -46,6 +46,7 @@
   },
   "dependencies": {
     "@cloudflare/vite-plugin": "^1.51.1",
+    "@fontsource-variable/geist-mono": "^5.3.0",
     "@fontsource-variable/inter": "^5.3.0",
     "@hey-api/openapi-ts": "0.0.0-next-20260824173136",
     "@orpc/client": "^1.15.0",
@@ -63,6 +64,7 @@
     "@tiptap/extension-table": "^3.30.3",
     "@tiptap/extensions": "^3.30.3",
     "@tiptap/markdown": "^3.30.3",
+    "@tiptap/pm": "^3.30.3",
     "@tiptap/react": "^3.30.3",
     "@tiptap/starter-kit": "^3.30.3",
     "@vitejs/plugin-react": "^6.0.3",

package/scaffold/.agents/skills/hitch-applets/SKILL.md

@@ -157,7 +157,7 @@ If a command fails, report the exact blocker. Do not deploy as a verification st
 ## Deploy from GitHub
 
 - A push to the production branch runs `applet deploy` in the workspace root through GitHub Actions.
-- An applet deploys when its own folder changed since its current CI release. Every applet deploys when a file outside `applets/` changed. An applet without a CI release always deploys. An applet also deploys when CI cannot load the commit of its current release.
+- An applet deploys when its folder or a file outside `applets/` differs from its current release, including a local `applet deploy`. Uncommitted and untracked files count. Gitignored files do not count. An applet whose current release has no source hash always deploys.
 - The deploy skips other applets and logs the reason. A skip is expected, not a failure.
 - A schema change in Hitch alone does not trigger CI.
 - Do not import from a sibling applet folder. The change check does not follow such imports.

package/scaffold/.agents/skills/hitch-applets/references/markdown.md

@@ -15,6 +15,8 @@ import { MarkdownEditor } from "@hitch42/applet/react";
 <MarkdownEditor value={value} onChange={setValue} files={hitch.files} />;
 ```
 
+Pass `autoFocus` to put the cursor at the end of the text when the editor mounts. It is off by default, so the editor never takes focus from another field.
+
 The editor uploads pasted or dropped images. It stores each image as `![name](hitch-file://<file-id>)`.
 
 The `files` value must supply both `upload(file)` and `download(id)`. The editor uses `download(id)` to show stored Hitch images.

package/scaffold/.agents/skills/hitch-theory/SKILL.md

@@ -45,7 +45,7 @@ Applets can be used standalone via their `.app` URL or within the Hitch shell. S
 
 The organization's Hitch data is the single source of truth. An applet reads and writes that data. It does not keep its own copy.
 
-The data layer stands on its own so that every way of using it is a client of the same thing. An applet, the `hitch` command line, an MCP server for an AI agent, an API key in a script, and an import all speak to the same objects, the same schema, and the same permissions. None of them is a bridge bolted on later. Each one is generated from the organization's own schema, so it knows the organization's objects by name. Each one acts as the person or applet behind it, so it sees exactly what that caller may see. The result is that a person in a browser, an agent in a chat window, and a script in a terminal all work on the same records under the same rules, and each gets the interface that suits them. Software stops being one product with one screen and becomes your organizational data with many doors.
+The data layer stands on its own so that every way of using it is a client of the same thing. An applet, the `hitch` command line, an MCP server for an AI agent, an API key in a script, and an import all speak to the same objects, the same schema, and the same permissions. None of them is a bridge bolted on later. The CLI and applet doors are generated from the organization's own schema. The MCP door has a fixed set of record tools and reads each object's live schema at runtime with `get_object_schema`. Each one acts as the person or applet behind it, so it sees exactly what that caller may see. The result is that a person in a browser, an agent in a chat window, and a script in a terminal all work on the same records under the same rules, and each gets the interface that suits them. Software stops being one product with one screen and becomes your organizational data with many doors.
 
 The boundary gives you:
 

package/scaffold/.github/workflows/hitch.yml

@@ -12,4 +12,4 @@ jobs:
       contents: read
       id-token: write
     # Hitch verifies the called workflow's commit SHA from the OIDC token.
-    uses: hitch-42/actions/.github/workflows/deploy.yml@1a76e4936f94730e20710b455fa0a06564929f39
+    uses: hitch-42/actions/.github/workflows/deploy.yml@cc7ab4f6eba51b31f73b0deaef4f6b86d43dc0dd

package/scaffold/applet/src/client/styles/globals.css

@@ -2,6 +2,7 @@
 @import "tw-animate-css";
 @import "shadcn/tailwind.css";
 @import "@fontsource-variable/inter";
+@import "@fontsource-variable/geist-mono";
 
 @source "../../../node_modules/@hitch42/applet/dist/react.js";
 @source "../../../node_modules/streamdown/dist/*.js";
@@ -12,6 +13,7 @@
 @theme inline {
   --font-heading: var(--font-sans);
   --font-sans: "Inter Variable", sans-serif;
+  --font-mono: "Geist Mono Variable", monospace;
   --color-sidebar-ring: var(--sidebar-ring);
   --color-sidebar-border: var(--sidebar-border);
   --color-sidebar-accent-foreground: var(--sidebar-accent-foreground);

package/dist/build-CcT-wNN9.js

@@ -1,2 +0,0 @@
-import { i as runBuild } from "./build-BlmLiKro.js";
-export { runBuild };

package/dist/generate-wIN3IYqL.js

@@ -1,2 +0,0 @@
-import { n as runGenerate } from "./generate-XB-72Fzj.js";
-export { runGenerate };