release: v0.1.3

.github/workflows/rust.yml

@@ -0,0 +1,85 @@
+name: rust
+
+on:
+  push:
+    branches: [dev, main]
+    paths:
+      - 'crates/**'
+      - 'Cargo.toml'
+      - 'Cargo.lock'
+      - 'rust-toolchain.toml'
+      - '.github/workflows/rust.yml'
+  pull_request:
+    branches: [dev, main]
+    paths:
+      - 'crates/**'
+      - 'Cargo.toml'
+      - 'Cargo.lock'
+      - 'rust-toolchain.toml'
+      - '.github/workflows/rust.yml'
+
+concurrency:
+  group: rust-${{ github.workflow }}-${{ github.ref }}
+  cancel-in-progress: true
+
+permissions:
+  contents: read
+
+env:
+  CARGO_TERM_COLOR: always
+  RUST_BACKTRACE: 1
+
+jobs:
+  fmt:
+    name: cargo fmt
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: dtolnay/rust-toolchain@stable
+        with:
+          components: rustfmt
+      - run: cargo fmt --all -- --check
+
+  clippy:
+    name: cargo clippy
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: dtolnay/rust-toolchain@stable
+        with:
+          components: clippy
+      - uses: Swatinem/rust-cache@v2
+      - run: cargo clippy --workspace --all-targets -- -D warnings
+
+  test:
+    name: cargo test
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: dtolnay/rust-toolchain@stable
+      - uses: Swatinem/rust-cache@v2
+      - run: cargo test --workspace
+
+  ts-bindings:
+    name: ts-rs bindings up to date
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: dtolnay/rust-toolchain@stable
+      - uses: Swatinem/rust-cache@v2
+      - run: cargo test -p kindling-types --features ts-rs
+      - name: Fail if bindings drifted
+        run: |
+          if ! git diff --exit-code -- crates/kindling-types/bindings; then
+            echo "::error::TypeScript bindings are out of date. Run: cargo test -p kindling-types --features ts-rs"
+            exit 1
+          fi
+
+  build:
+    name: cargo build --release
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: dtolnay/rust-toolchain@stable
+      - uses: Swatinem/rust-cache@v2
+      - run: cargo build --workspace --release

.gitignore

@@ -158,3 +158,8 @@ settings.local.json
 
 # Admin-only files (publishing, plans, internal checklists)
 admin/
+
+# Rust
+target/
+**/*.rs.bk
+*.pdb

CHANGELOG.md

@@ -5,6 +5,49 @@ All notable changes to the Kindling project will be documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+> **Heads-up on the road to 1.0.0.** Kindling is being re-implemented in Rust
+> as the canonical engine, with `@eddacraft/kindling` repurposed as a thin
+> HTTP-over-UDS client that downloads the Rust binary at install time. The
+> existing TypeScript implementation packages (`-core`, `-store-sqlite`,
+> `-store-sqljs`, `-provider-local`, `-server`, `-cli`) are deprecated and
+> will be removed at 1.0.0. The 0.1.x line continues to receive maintenance
+> until the Rust cutover lands. See
+> `plans/specs/2026-05-03-rust-canonical-thin-client-design.md`.
+
+## [0.1.3] - 2026-05-08
+
+### Added
+
+- **CLI**: new `kindling log` and `kindling capsule` write commands, plus an
+  install script and a substantially expanded README with cross-platform
+  install guides.
+- **Claude Code plugin**: `recall` skill for agent memory retrieval, with
+  auto-invoke triggers and an explicit `/kindling:recall <query>` command.
+- **Cross-language schema contract**: `schema/schema.sql` and
+  `schema/version.json` are now the canonical SQLite schema for both the
+  TypeScript store and the upcoming Rust store (SCHEMA-001..005).
+- **Main package README** with cross-platform install instructions for
+  `@eddacraft/kindling`.
+
+### Changed
+
+- **Dependencies**: bumped `fastify` 5.7.4 → 5.8.1 in `kindling-server`.
+- **Repository structure**: `packages/kindling-api-server/` renamed to
+  `packages/kindling-server/` to match the npm package name. The published
+  package name (`@eddacraft/kindling-server`) is unchanged — no consumer
+  action required.
+
+### Internal
+
+- Adopted the `main`/`dev` branching model: feature work merges to `dev`,
+  releases promote `dev` → `main`, GitHub Releases on `main` trigger
+  `publish.yml`. Documented in `docs/guides/`.
+- Replaced `prettier` with `oxfmt` for formatting.
+- Rebuilt the Claude Code plugin bundle.
+- Began the Rust port (Phase 1, foundation): workspace scaffold landed in
+  `crates/`. The crates are not published to npm and have no impact on this
+  release — see the heads-up above.
+
 ## [0.1.2] - 2026-02-16
 
 ### Changed

CLAUDE.md

@@ -127,14 +127,34 @@ ESM-only (`"type": "module"`) with `.js` extensions in imports.
 
 ## Branching Workflow
 
-```
-feature branches → dev (default) → main (releases/publishing)
-```
+This repository uses a `main`/`dev` model that supports multiple active
+streams in parallel worktrees.
+
+- `main` is the stable release branch.
+- `dev` is the active integration branch.
+- normal feat, fix, docs, and chore branches are created from `dev`.
+- hotfix branches are created from `main` or the active `release/*` branch.
+
+Keep `main` and `dev` as the only permanent worktrees. Treat all other
+worktrees as disposable and remove them once the branch is merged, replaced,
+or paused.
+
+Release guidance:
+
+- small releases may promote directly from `dev` to `main`
+- larger releases should use a short-lived `release/*` branch
+- any fix that lands during release stabilisation must be merged back to `dev`
+  immediately after release
+- tagging `vX.Y.Z` on `main` and creating a GitHub Release triggers
+  `.github/workflows/publish.yml`, which publishes all packages to npm
+
+See the detailed guides for the full policy:
+
+- `docs/guides/branching-strategy.md`
+- `docs/guides/worktree-policy.md`
+- `docs/guides/release-runbook.md`
 
-- **`dev`** is the default branch. All feature branches are created from and merged into `dev` via PR.
-- **`main`** is the release branch. Only `dev` → `main` PRs are merged here, and these trigger npm publishing.
-- CI runs on pushes and PRs to both `dev` and `main`.
-- Never push directly to `main` or `dev` — always use pull requests.
+Never push directly to `main` or `dev` — always use pull requests.
 
 ## PocketFlow (Vendored)
 

CONTRIBUTING.md

@@ -56,27 +56,43 @@ pnpm clean
 
 ## Branching Model
 
-This project uses a two-tier branching workflow:
+Kindling uses a two-branch model that supports multiple active streams in
+parallel worktrees:
 
-```
-feature branches → dev (default) → main (releases)
-```
+- `main` is the stable release branch. Always publishable to npm.
+- `dev` is the active integration branch and the default branch.
+- normal feat, fix, docs, and chore branches are created from `dev`.
+- hotfix branches are created from `main` or the active `release/*` branch.
+
+Keep `main` and `dev` as the only permanent worktrees. Treat all other
+worktrees as disposable and remove them once the branch is merged, replaced,
+or paused.
+
+Release guidance:
+
+- small releases may promote directly from `dev` to `main`
+- larger releases should use a short-lived `release/*` branch
+- any fix that lands during release stabilisation must be merged back to `dev`
+  immediately after release
+
+See the detailed guides for the full policy:
 
-- **`dev`** is the default branch and integration target for all development.
-- **`main`** is the release branch. Merges into `main` trigger publishing.
-- **Feature branches** are created from `dev` and merged back via PR.
-- PRs into both `dev` and `main` require CI to pass.
-- Only maintainers merge `dev` → `main` for releases.
+- [`docs/guides/branching-strategy.md`](docs/guides/branching-strategy.md)
+- [`docs/guides/worktree-policy.md`](docs/guides/worktree-policy.md)
+- [`docs/guides/release-runbook.md`](docs/guides/release-runbook.md)
 
 ## Pull Request Process
 
 1. **Open an issue first** for significant changes to discuss approach
-2. **Create a feature branch** from `dev`
+2. **Create a branch from `dev`** for normal work, or from `main` only for
+   production hotfixes
 3. **Write tests** for new functionality
 4. **Update documentation** if behavior changes
-5. **Keep PRs focused** - one logical change per PR
-6. **Ensure CI passes** before requesting review
-7. **Target `dev`** — PRs should target the `dev` branch, not `main`
+5. **Keep PRs focused** — one logical change per PR
+6. **Run the full test suite**: `pnpm build && pnpm test && pnpm lint`
+7. **Ensure CI passes** before requesting review
+8. **Target `dev`** — feature PRs should target `dev`, not `main`. Only
+   release-promotion and hotfix PRs target `main`.
 
 ### Commit Messages