@authorbot/schemas 0.1.33 → 0.1.35

package/CHANGELOG.md

@@ -9,6 +9,72 @@ Every published package shares this version. A tag builds, tests, and publishes
 all of them together, so `@authorbot/cli@0.1.15` and `@authorbot/api@0.1.15` are
 always the same commit.
 
+## 0.1.35
+
+- **Legacy agent-token requests now maintain the canonical projection.** The
+  compatibility `{scopes}` request remains legacy-authoritative, but every new
+  token also records the exact safe capability translation. Control-plane
+  scopes never enter that projection. This dual-write Worker must be deployed
+  and verified before the one-shot legacy-row backfill ships in v0.1.36.
+- **The upgrade helper now repairs a stale local toolchain before changing a
+  book.** Forward upgrades hand off to the exact target CLI in a throwaway
+  install when `node_modules` does not match the repository pin. That target
+  aligns the CLI and API packages, regenerates the lockfile, and preserves the
+  child exit code and JSON output. Interrupted same-version installs are
+  repaired through a normal reviewable pull request, with migration baselines
+  accepted only from coherent committed CLI lock evidence. Dry runs regenerate
+  and verify the lockfile in a throwaway copy. Windows launches npm, npx, and
+  Wrangler through validated JavaScript entry points under the current Node
+  executable, without enabling a command shell. Exact `--to` targets require
+  no registry metadata lookup; implicit discovery uses npm's configured
+  offline cache, registry, userconfig, and authentication. Existing helpers
+  from before 0.1.35 still need one explicit
+  `npx --yes @authorbot/cli@0.1.35 upgrade --to 0.1.35` launch; ordinary
+  `npx authorbot upgrade` self-bootstraps after that.
+- This is a focused capability-writer-gate and upgrade-safety release. It adds
+  no D1 or book-format migration. The Phase 3B backfill is reserved for
+  v0.1.36 after this Worker is verified; Phase 3C legacy retirement remains a
+  deliberately separate later release.
+
+## 0.1.34
+
+- **The full editorial workflow is now available from the site.** Editors can
+  revise chapters with Milkdown Crepe, edit Outline, Timeline, and Character
+  documents in place, submit immutable proposals, and review safe Diff2Html
+  diffs. Maintainers can apply their own edit in one action without bypassing
+  validation, attribution, Git history, or the deployment pipeline.
+- **Notes and discussion now work as complete chapter collaboration tools.**
+  Anchored notes stay in manuscript order, expand with their target, navigate
+  with Previous and Next controls, render inline on mobile, and share the
+  Milkdown reading surface. Chapter-wide discussion supports replies, comment
+  voting, withdrawal, moderation, and one-click promotion to Work.
+- **Work and revision progress remains visible.** Completed Work stays on the
+  Work page with attribution and result links. Submitted edits report review,
+  apply, repository, build, and deployment state while retaining recoverable
+  drafts until the matching commit is live.
+- **Agent permissions are exact and human-equivalent for editorial work.**
+  Tokens can independently read and write comments and suggestions, vote,
+  reply, work a lease, submit revisions, review proposals, read history, and
+  update summaries within their role ceiling. Control-plane authority remains
+  human-only. Token event feeds and operation polling now enforce those same
+  exact read capabilities instead of exposing unrelated project activity. The
+  collaborator skill documents these workflows and exposes a bounded
+  story-bible API so agents do not have to probe a deployed site.
+- **Editors load reliably on nested and mobile sites.** Books served from a
+  base path keep lazy editor styles under that path. Mobile note forms stay
+  reachable beside their manuscript target, and rich Notes rerenders replace
+  the existing composer instead of duplicating it.
+- **Chapter context is easier to understand and recover.** Chapter rows show
+  open feedback and Work counts, summaries flow into the authenticated and
+  published Outline views, contributors link to the accepted revisions that
+  credited them, and authorized collaborators can browse, compare, and propose
+  restoring earlier chapter versions.
+- This release includes D1 migrations `0010_phase11_capabilities_expand.sql`,
+  `0011_phase11_revision_proposals.sql`, and
+  `0012_chapter_summaries.sql`. The capability backfill deliberately remains a
+  separate later release after this dual-read Worker is deployed. No
+  book-format migration is required.
+
 ## 0.1.33
 
 - **Collaboration state now stays coherent across the whole site.** Account,

package/dist/annotation.d.ts

@@ -157,7 +157,9 @@ export type Annotation = z.infer<typeof annotationSchema>;
  * Reply frontmatter `.authorbot/annotations/<id>/replies/<reply-id>.md` -
  * `authorbot.reply/v1`. The contract pins only the schema ID; fields follow
  * the Reply entity of design section 9.1 (ID, annotation ID, optional parent
- * reply, author, timestamps). The reply body is the Markdown content itself.
+ * reply, author, timestamps). `status` is optional for compatibility with
+ * artifacts written before reply withdrawal shipped; absence means `open`.
+ * The reply body is the Markdown content itself.
  */
 export declare const replySchema: z.ZodObject<{
     schema: z.ZodLiteral<"authorbot.reply/v1">;
@@ -165,6 +167,10 @@ export declare const replySchema: z.ZodObject<{
     annotation_id: z.ZodString;
     parent_reply_id: z.ZodOptional<z.ZodString>;
     author: z.ZodString;
+    status: z.ZodOptional<z.ZodEnum<{
+        open: "open";
+        withdrawn: "withdrawn";
+    }>>;
     created_at: z.ZodString;
     updated_at: z.ZodOptional<z.ZodString>;
 }, z.core.$strict>;

package/dist/annotation.js

@@ -82,7 +82,9 @@ export const annotationSchema = z.discriminatedUnion("scope", [
  * Reply frontmatter `.authorbot/annotations/<id>/replies/<reply-id>.md` -
  * `authorbot.reply/v1`. The contract pins only the schema ID; fields follow
  * the Reply entity of design section 9.1 (ID, annotation ID, optional parent
- * reply, author, timestamps). The reply body is the Markdown content itself.
+ * reply, author, timestamps). `status` is optional for compatibility with
+ * artifacts written before reply withdrawal shipped; absence means `open`.
+ * The reply body is the Markdown content itself.
  */
 export const replySchema = z.strictObject({
     schema: z.literal("authorbot.reply/v1"),
@@ -90,6 +92,7 @@ export const replySchema = z.strictObject({
     annotation_id: uuidv7Schema,
     parent_reply_id: uuidv7Schema.optional(),
     author: actorRefSchema,
+    status: z.enum(["open", "withdrawn"]).optional(),
     created_at: timestampSchema,
     updated_at: timestampSchema.optional(),
 });

package/dist/json-schemas.d.ts

@@ -263,6 +263,10 @@ export declare const artifactSchemas: {
         annotation_id: z.ZodString;
         parent_reply_id: z.ZodOptional<z.ZodString>;
         author: z.ZodString;
+        status: z.ZodOptional<z.ZodEnum<{
+            open: "open";
+            withdrawn: "withdrawn";
+        }>>;
         created_at: z.ZodString;
         updated_at: z.ZodOptional<z.ZodString>;
     }, z.core.$strict>;

package/json/reply.schema.json

@@ -23,6 +23,13 @@
       "type": "string",
       "pattern": "^(?:github|agent|system):[A-Za-z0-9][A-Za-z0-9._-]*$"
     },
+    "status": {
+      "type": "string",
+      "enum": [
+        "open",
+        "withdrawn"
+      ]
+    },
     "created_at": {
       "type": "string",
       "pattern": "^\\d{4}-(?:0[1-9]|1[0-2])-(?:0[1-9]|[12]\\d|3[01])T(?:[01]\\d|2[0-3]):[0-5]\\d:(?:[0-5]\\d|60)(?:\\.\\d{1,9})?Z$"

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@authorbot/schemas",
-  "version": "0.1.33",
+  "version": "0.1.35",
   "description": "Zod v4 schemas, inferred TypeScript types, and generated JSON Schemas for Authorbot book-repository artifacts (Phase 0 contract section 4)",
   "keywords": [
     "authorbot",