Add Changesets and GitHub Actions automation - #4

The real moat of metadata-driven development is not 'low-code UI', it
is that the entire business system is small enough to fit in an AI
agent's context window. Make this an explicit, top-level value across
README and the concept docs.

- README.md
  - Add a 'Key Features' bullet on ~100x less code -> AI maintainability
  - Add 'Code footprint' and 'AI maintainability' rows to the
    Retool/Appsmith comparison table
  - Rewrite the 'Why AI-native?' intro to anchor the value on
    'fit in an agent's context window'

- content/docs/index.mdx
  - Add a second callout under the 'not a low-code UI builder' line
    explaining the ~100x code reduction and AI-co-maintenance angle
  - Fix stale 'npx @objectstack/cli init' -> 'npx create-objectstack'
    quick-start command (matches updated README)

- content/docs/concepts/metadata-driven.mdx
  - Rename benefit #4 'Reduced Boilerplate' -> '~100x Less Code -
    Sized for AI Agents' and reframe around context-window fit
  - Clarify that what gets generated is full CRUD + REST + typed SDK
    + MCP tools + validation + permission scaffolding, not just CRUD

- content/docs/concepts/north-star.mdx
  - Add a sixth non-negotiable tenet: 'Compact by Construction'
    -> a typical enterprise app fits in ~1% of a hand-written
    equivalent, small enough for an AI agent to load and refactor
    end-to-end. Explicitly call this out as the real moat.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Introduces an opt-in path in ObjectStackProtocolImplementation.saveMetaItem
that writes overlay metadata through SysMetadataRepository.put instead of
the raw engine, so writes append to the change-log and emit HMR seq events.

Behavioural changes (all behind options.useRepositoryWritePath /
OBJECTSTACK_USE_REPOSITORY_WRITE_PATH=1):
- saveMetaItem request gained optional parentVersion (If-Match) and
  actor fields. ConflictError -> 409 metadata_conflict.
- Plural type aliases (views, dashboards, ...) normalized to singular
  before the repo's overlay-allowlist gate (rubber-duck #5).
- Object-registry mutation moved AFTER successful put() so a conflict
  does not leave the in-memory registry stale (rubber-duck #3 invariant
  test added).

Repo/test-fake fixes uncovered by rubber-duck review:
- SysMetadataRepository.put/delete now update/delete by row id because
  the engine's strict .update requires id or multi:true (rubber-duck #1).
- sys_metadata.checksum column widened from 64 -> 71 chars to hold the
  sha256: prefix produced by hashSpec() (rubber-duck #2).
- Three test fake engines extended to support both overlay-tuple and
  id-based where lookups.

333/333 objectql tests pass.

Deferred to PR-10d.4: REST plumbing for parentVersion/actor
(rubber-duck #6), race-window retry for omitted parentVersion
(rubber-duck #4), default flag flip + legacy path removal.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Proposes that every Action opts in to AI exposure via a single `ai:` block
on ActionSchema, and the runtime auto-derives AIToolDefinitions from the
existing ActionRegistry. Eliminates the need to maintain parallel skill /
tool code for every business operation an admin can already perform.

- Adds opt-in `ai: { exposed, description, paramHints, outputSchema, ... }`
  block to @objectstack/spec ui/action.zod.ts
- Adds ActionRegistry.toolsForAi(opts) in @objectstack/runtime
- Wires service-ai/agent-runtime to merge action-tools into availableTools
- Routes LLM tool_calls with meta.kind='action' through ActionRegistry so
  permissions, validation, hooks, audit, and transactions all apply uniformly
- Confirmation defaults derived from existing confirmText / type='delete'

Authored from HotCRM v1.1 planning. HotCRM will be the first consumer:
delete src/skills/, convert each business skill to defineAction with ai
exposed, ship the 'Operational Parity' story as Wow #4.

Refs ADR-0003, ADR-0008, ADR-0009, ADR-0010.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

#1821)

Small models (e.g. claude-haiku) sometimes answered a "draw a bar chart"
request with a markdown TABLE — running query_data/aggregate_data and
formatting the numbers — instead of calling visualize_data. This was a
tool-selection problem, not a capability gap: the chart preference was buried
as guideline #7 and competed with guideline #4 ("format with markdown
tables").

- data-explorer-skill.ts: add a prominent "Choosing the right tool" section
  ABOVE the guidelines — chart intent (incl. CN terms 图表/柱状图/折线图/饼图/画图)
  → MUST call visualize_data; never substitute a table; reconcile the
  table-formatting guideline; fix duplicate guideline numbering.
- visualize-data.tool.ts: strengthen the tool description to be imperative
  ("the ONLY tool that draws a chart… you MUST call this, not a table; if you
  already fetched the numbers, still call visualize_data to render them").

Prompt-only tuning — no behavior/contract change. Raises the likelihood the
model reaches for visualize_data on a plain chart request without an explicit
"use visualize_data" nudge.

Co-authored-by: Jack Zhuang <277994282+os-zhuang@users.noreply.github.com>
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…ss, with the CPU inversion designed out (objectstack-ai#11915)

The guard's only instrument was output flushes, measured at the wrong end of the
pipeline: what it sees is whatever the last buffering layer chose to release.
--log-order=stream closed one spelling of that; any future buffering layer
re-opens it and kills a healthy suite deterministically on an innocent diff.

Second signal: bytes every process in the wrapped group has passed to write(),
read from /proc/<pid>/io (wchar) — the same quantity the guard already trusts,
sampled at the SOURCE, before any buffering layer can hide it.

Measured first, because the card's CPU direction does not survive contact
(node 22, 2.5s sample, one process per shape):

    shape                        state  dCPU(ticks)  dwchar(bytes)
    idle hang (self-test objectstack-ai#4)     S                0              0
    sync-spinning hang (objectstack-ai#5)      R              251              0
    GC-thrash hang               R              272              0
    HEALTHY silent-but-working   S                1         25,542

CPU does not merely fail to separate these shapes, it separates them BACKWARDS:
the genuine hangs peg a core while the healthy suite the probe exists to protect
is nearly idle, because it is I/O-bound — it is busy writing. wchar separates all
four correctly.

The probe is a confirming signal in one direction only. No output and no
source-side bytes still kills at --stall-minutes with no added latency (idle and
spinning hangs write nothing, so neither is ever deferred). No output but bytes
still moving defers the kill, announced loudly — a live suite hidden by a
buffering layer is a bug to fix, not to tolerate — and only as far as
--stall-cap-minutes, after which the group dies under a distinct STALL-CAP
verdict. That cap is what stops the probe turning "kills healthy suites" into
"never fires on spin hangs", which is strictly worse. A cap <= the window is
refused; an unreadable /proc/<pid>/io reports UNAVAILABLE and the guard behaves
exactly as before.

--stall-minutes is untouched.


Claude-Session: https://claude.ai/code/session_015ahemw8RcTgqtxrj15PEZx

Co-authored-by: Claude <noreply@anthropic.com>