memory-journal-mcp 7.7.0 → 8.0.0

package/skills/docs-marketer/references/multi-pass-docs-protocol.md

@@ -0,0 +1,410 @@
+# Multi-Pass Docs Marketing Protocol
+
+Detailed reference for the documentation marketability audit pipeline. This
+document defines the full review dimensions, scoring system, and output
+templates for both standard (single-pass) and adversarial (dual-agent) modes.
+
+## Phase 0 — Research (Agent A: The Marketer)
+
+Before starting the audit, gather context:
+
+0. **Target repository resolution** — determine which repository to audit:
+   - If the user specified a repository, resolve its absolute path via
+     workspace roots or `PROJECT_REGISTRY`.
+   - If the user invoked the skill without specifying a target (e.g., via a
+     slash command or "run the docs audit"), follow the resolution logic in
+     `SKILL.md § Target Resolution`: check workspace context, infer from
+     conversation, or ask the user.
+   - Confirm the target path in your output before proceeding (e.g.,
+     "Auditing: `C:\Users\chris\Desktop\memory-journal-mcp`").
+   - `Set-Location` (or `cd`) to the target repository for all subsequent
+     file reads and Copilot invocations.
+1. **Documentation surface discovery** — identify all doc targets:
+   - `README.md` (primary)
+   - `DOCKER_README.md` (Docker Hub — 25,000 char limit)
+   - Wiki clone (`.wiki/` directory — check `<repo>.wiki/` sibling path)
+   - npm package README (may differ from repo README)
+   - MCP Registry listing (`server.json`)
+   - GitHub repository description and topics
+2. **Source code capabilities** — enumerate features the project actually has:
+   - Tool groups and tool counts (from `tool-filter.ts` or `tool-constants.ts`)
+   - Environment variables (from CLI flags and `.env.example`)
+   - Resources, prompts, transport modes
+   - Security features (OAuth, rate limiting, CORS)
+   - Unique differentiators (Code Mode, briefing system, etc.)
+3. **Prior audits** — search the journal:
+   ```
+   search_entries({
+     query: "docs marketing audit",
+     entry_type: "docs_marketing_profile",
+     tags: ["docs-marketer"]
+   })
+   ```
+4. **Competitor landscape** — if the project has an MCP Registry listing,
+   briefly research similar projects to understand competitive positioning.
+
+---
+
+## Phase 1 — Document Surface Inventory (Agent A: The Marketer)
+
+### Inputs
+
+For each discovered documentation surface, read its full content and evaluate
+against all 10 audit categories.
+
+### Per-Surface Scorecard
+
+```markdown
+### [Surface Name] (e.g., README.md)
+
+**Size**: X lines, Y KB
+**Last Modified**: [date if available]
+**Platform Constraints**: [e.g., Docker Hub 25K char limit]
+
+| Category                       | Score (1–5) | Notes |
+| ------------------------------ | ----------- | ----- |
+| 1. Feature Visibility          |             |       |
+| 2. First Impression            |             |       |
+| 3. Information Architecture    |             |       |
+| 4. Visual Assets               |             |       |
+| 5. Competitive Differentiation |             |       |
+| 6. Onboarding Friction         |             |       |
+| 7. Platform Presence           |             |       |
+| 8. Cross-Document Consistency  |             |       |
+| 9. Tone & Voice                |             |       |
+| 10. SEO & Discoverability      |             |       |
+| **Average**                    | **X.X**     |       |
+
+**Top Opportunity**: [Single highest-impact marketing improvement]
+**Grade**: [A–F]
+```
+
+### Feature Visibility Gap Analysis
+
+Cross-reference discovered capabilities against documentation mentions:
+
+```markdown
+### Feature Visibility Gaps
+
+| Capability                    | In Source? | In README? | In Wiki? | In Docker? | Marketing Status         |
+| ----------------------------- | ---------- | ---------- | -------- | ---------- | ------------------------ |
+| Code Mode (90% token savings) | ✅         | ✅         | ✅       | ❌         | Under-marketed in Docker |
+| Hush Protocol flags           | ✅         | ✅         | ⚠️ Brief | ❌         | Under-marketed           |
+| OAuth 2.1 (RFC 9728)          | ✅         | ✅         | ❌       | ❌         | Missing from Wiki/Docker |
+```
+
+### Scoring Guide
+
+| Score | Meaning                                                          |
+| ----- | ---------------------------------------------------------------- |
+| 5     | Excellent — compelling, well-structured, clearly differentiating |
+| 4     | Good — solid coverage, minor marketing opportunities missed      |
+| 3     | Acceptable — features documented but not effectively marketed    |
+| 2     | Poor — significant capabilities buried or poorly presented       |
+| 1     | Failing — misleading, empty, or actively harmful to adoption     |
+
+### Portfolio Overview
+
+After scoring all surfaces individually, produce a portfolio-level overview:
+
+```markdown
+## Documentation Portfolio Overview
+
+**Surfaces Audited**: N
+**Average Marketing Score**: X.X / 5.0
+**Portfolio Grade**: [A–F]
+
+### Score Distribution
+
+| Grade       | Surfaces         |
+| ----------- | ---------------- |
+| A (4.5–5.0) | README.md        |
+| B (3.5–4.4) | Wiki Home        |
+| C (2.5–3.4) | DOCKER_README.md |
+| D (1.5–2.4) | —                |
+| F (1.0–1.4) | —                |
+
+### Cross-Surface Properties
+
+- **Feature gaps**: [capabilities missing from specific surfaces]
+- **Consistency issues**: [conflicting counts, outdated version numbers]
+- **Platform violations**: [Docker Hub char limit, npm README truncation]
+- **Strongest surface**: [which document best markets the project]
+- **Weakest surface**: [which needs the most marketing improvement]
+```
+
+### Journal (Phase 1)
+
+```
+create_entry({
+  content: "<full inventory with all scorecards + gap analysis>",
+  entry_type: "docs_marketing_profile",
+  tags: ["docs-marketer", "profile"],
+  project_number: <project number>
+})
+```
+
+### Standard Mode: Skip to Phase 3
+
+In **standard mode** (`AUDIT_DEPTH: standard`), skip Phase 2 entirely and
+proceed directly to Phase 3 (Improvement Plan) using the Phase 1 findings.
+
+---
+
+## Phase 2 — Skeptical Reader Review (Agent B: The First-Time Evaluator)
+
+> **Only runs in adversarial mode** (`AUDIT_DEPTH: adversarial`).
+
+Switch mental models. You are now a developer who has never seen this project
+before. You have 5 minutes to decide whether to adopt it or move on. Your job
+is to find where the documentation fails to sell the project.
+
+### Review Dimensions
+
+Score each dimension on a 1–5 scale:
+
+| Dimension                | Weight | Focus Areas                                                                                                                    |
+| ------------------------ | ------ | ------------------------------------------------------------------------------------------------------------------------------ |
+| **30-Second Test**       | 4      | Can someone understand the value proposition in 30 seconds of scanning? Is the tagline clear? Does the badge row convey trust? |
+| **Competitive Survival** | 3      | If choosing between this and an alternative, what would make you leave? What claims feel weak?                                 |
+| **Onboarding Friction**  | 3      | Follow the Quick Start literally — where do you get stuck, confused, or need to context-switch?                                |
+| **Feature Discovery**    | 2      | What powerful capabilities are buried? What would surprise a user who only read the first 3 sections?                          |
+| **Trust Signals**        | 2      | Test coverage badges, security claims, maintenance signals — do they feel authentic?                                           |
+
+### The 30-Second Test
+
+Read only the first screen (~40 lines) of the README. Answer:
+
+1. What does this project do?
+2. Why should I use it instead of alternatives?
+3. How do I get started?
+
+If any answer is unclear, that's a finding.
+
+### Competitive Evaluation
+
+```markdown
+### Competitive Survival Test
+
+| Question                                                | Answer | Score (1–5) |
+| ------------------------------------------------------- | ------ | ----------- |
+| Is the value prop clear in the tagline?                 |        |             |
+| Does the feature table differentiate or just list?      |        |             |
+| Are comparisons to alternatives explicit or implied?    |        |             |
+| Would a skeptic find the claims credible?               |        |             |
+| Is there social proof (stars, downloads, testimonials)? |        |             |
+```
+
+### Under-Marketed Features Audit
+
+Identify capabilities that exist in source code but are:
+
+- **Buried**: Mentioned only deep in the README (below fold)
+- **Understated**: Mentioned briefly without explaining impact
+- **Missing**: Not documented at all in any surface
+- **Poorly positioned**: Documented but framed as technical detail instead of
+  user benefit
+
+### Oversold Features Audit
+
+Identify claims that:
+
+- Use superlatives without evidence ("best", "fastest", "most comprehensive")
+- Quote metrics without context (e.g., "90% token savings" — compared to what?)
+- Claim features that are opt-in or require significant setup as defaults
+
+### Critique Output Format
+
+```markdown
+## Skeptical Reader Review — [Repository Name]
+
+**Overall Marketing Score:** [weighted average] / 5.0
+**Portfolio Grade:** [A–F]
+
+### Findings
+
+| #   | Surface | Category           | Severity | Finding                            | Recommendation                            |
+| --- | ------- | ------------------ | -------- | ---------------------------------- | ----------------------------------------- |
+| 1   | README  | First Impression   | High     | Value prop unclear in tagline      | Rewrite tagline to lead with user benefit |
+| 2   | Docker  | Feature Visibility | Critical | Missing Code Mode section entirely | Add condensed Code Mode section           |
+| 3   | Wiki    | Onboarding         | Medium   | Quick Start assumes GitHub token   | Add minimal non-GitHub path               |
+
+### Dimension Scores
+
+| Dimension            | Score | Weight | Weighted             |
+| -------------------- | ----- | ------ | -------------------- |
+| 30-Second Test       | [1–5] | 4      | [score × 4]          |
+| Competitive Survival | [1–5] | 3      | [score × 3]          |
+| Onboarding Friction  | [1–5] | 3      | [score × 3]          |
+| Feature Discovery    | [1–5] | 2      | [score × 2]          |
+| Trust Signals        | [1–5] | 2      | [score × 2]          |
+| **Total**            |       | **14** | **[sum]/70 = [avg]** |
+
+### Blocking Issues
+
+Findings that are actively hurting adoption or creating misleading impressions.
+```
+
+### Journal (Phase 2)
+
+```
+create_entry({
+  content: "<full skeptical reader review>",
+  entry_type: "docs_marketing_critique",
+  tags: ["docs-marketer", "critique"],
+  project_number: <project number>
+})
+```
+
+---
+
+## Phase 3 — Improvement Plan (Agent A: The Marketer)
+
+Switch back to the Marketer. Address every finding with a disposition.
+
+### Disposition Table
+
+| Disposition | Meaning                                           |
+| ----------- | ------------------------------------------------- |
+| **Accept**  | Implement the improvement                         |
+| **Reject**  | Finding doesn't apply or trade-off isn't worth it |
+| **Modify**  | Accept the spirit but implement differently       |
+| **Defer**   | Acknowledge but defer (document why)              |
+
+### Improvement Plan Output
+
+```markdown
+## Improvement Plan — [Repository Name]
+
+### Disposition Summary
+
+| #   | Surface | Finding           | Disposition | Rationale                         |
+| --- | ------- | ----------------- | ----------- | --------------------------------- |
+| 1   | README  | Tagline unclear   | Accept      | Rewrite to lead with user benefit |
+| 2   | Docker  | Missing Code Mode | Accept      | Add condensed section             |
+| 3   | Wiki    | Assumes GitHub    | Modify      | Add note instead of full rewrite  |
+
+### Priority 1 — Quick Wins (<15 minutes per fix)
+
+| Surface | Fix                     | Impact           |
+| ------- | ----------------------- | ---------------- |
+| README  | Update stale badge URLs | Trust            |
+| GitHub  | Add missing topics      | SEO              |
+| README  | Strengthen tagline      | First Impression |
+
+### Priority 2 — Structural Improvements (30–60 minutes)
+
+| Surface | Fix                                         | Impact             |
+| ------- | ------------------------------------------- | ------------------ |
+| README  | Reorder sections for progressive disclosure | IA                 |
+| Docker  | Add Code Mode summary section               | Feature Visibility |
+| Wiki    | Create comparison table vs. alternatives    | Differentiation    |
+
+### Priority 3 — Strategic Improvements (1–2 hours)
+
+| Surface | Fix                                                | Impact          |
+| ------- | -------------------------------------------------- | --------------- |
+| README  | Rewrite "What Sets Us Apart" with concrete metrics | Differentiation |
+| Wiki    | Create onboarding guide for non-GitHub users       | Onboarding      |
+| All     | Unify tone and voice across all surfaces           | Consistency     |
+
+### Projected Marketing Improvement
+
+| Metric                        | Before | After |
+| ----------------------------- | ------ | ----- |
+| Average marketing score       | X.X    | X.X   |
+| Surfaces graded A/B           | N/M    | N/M   |
+| Feature visibility gaps       | N      | N     |
+| Cross-surface inconsistencies | N      | N     |
+```
+
+### Iteration Control
+
+Check: has `MAX_AUDIT_PASSES` been reached?
+
+- **No** → return to Phase 2 (stress-test the improvement plan itself)
+- **Yes** → proceed to Phase 4
+
+### Journal (Phase 3)
+
+```
+create_entry({
+  content: "<improvement plan with dispositions>",
+  entry_type: "docs_marketing_remediation",
+  tags: ["docs-marketer", "remediation"],
+  project_number: <project number>
+})
+```
+
+---
+
+## Phase 4 — Copilot Validation (External)
+
+If available, invoke Copilot CLI. See
+[copilot-docs-prompts.md](copilot-docs-prompts.md).
+
+If unavailable, skip gracefully.
+
+### Journal (Phase 4)
+
+```
+create_entry({
+  content: "<copilot findings + final dispositions>",
+  entry_type: "docs_marketing_copilot",
+  tags: ["docs-marketer", "copilot"],
+  project_number: <project number>
+})
+```
+
+---
+
+## Final Report Assembly
+
+```markdown
+# Documentation Marketing Audit — [Repository Name]
+
+**Date**: [ISO date]
+**Audit Depth**: [standard | adversarial]
+**Surfaces Audited**: N
+**Passes Completed**: N
+**Copilot Validation**: [yes | skipped]
+
+## Executive Summary
+
+[2–3 sentences: overall marketing quality, critical gaps, top recommendation]
+
+**Portfolio Marketing Score**: [X.X] / 5.0 — Grade [A–F]
+
+## Surface Scoreboard
+
+| Surface          | Score | Grade | Top Opportunity                     |
+| ---------------- | ----- | ----- | ----------------------------------- |
+| README.md        | 4.2   | B     | Strengthen competitive positioning  |
+| DOCKER_README.md | 3.0   | C     | Missing Code Mode and Hush Protocol |
+| Wiki Home        | 3.8   | B     | Improve onboarding flow             |
+
+## Feature Visibility Gap Map
+
+[From Phase 1 — capabilities vs. documentation coverage]
+
+## Top 5 Marketing Improvements (by impact)
+
+1. [Highest-impact improvement]
+2. ...
+
+## Cross-Surface Consistency Issues
+
+[Conflicting information across surfaces]
+
+## Full Findings (by severity)
+
+[All findings from Phases 1–2]
+
+## Improvement Plan
+
+[From Phase 3 — prioritized with dispositions]
+
+## Per-Surface Scorecards
+
+[From Phase 1 — all individual scorecards]
+```

package/skills/drizzle-orm/SKILL.md

@@ -0,0 +1,82 @@
+---
+name: drizzle-orm
+description: |
+  Drizzle ORM best practices. Use when configuring databases, designing schemas, writing queries, or handling migrations with Drizzle ORM, particularly with Cloudflare D1 or SQLite. NOT for database setup without an explicit engine. Require engine specification (Postgres/MySQL/SQLite). Use for ORM-managed migrations.
+---
+
+# Drizzle ORM Guidelines
+
+This skill provides opinionated standards for using Drizzle ORM, optimized for TypeScript and edge databases like Cloudflare D1.
+
+## 1. Core Principles
+
+- **Single Source of Truth**: Define your database schema in TypeScript. Let Drizzle generate the SQL migrations.
+- **Explicit Returns**: Always explicitly select the columns you need using `.select({ id: table.id })`. Avoid `select *` in production queries to minimize payload size and improve performance.
+- **Relational Queries**: Use Drizzle's Relational Query API (`db.query`) for complex joined data fetching, but use the Core API (`db.select().from()`) for mutations and simple lookups.
+- **Type Inference**: Use `typeof schema.table.$inferSelect` and `$inferInsert` to generate application types directly from the schema.
+
+## 2. Schema Definition
+
+Always define schemas with precise types and constraints.
+
+```typescript
+import { sqliteTable, text, integer } from 'drizzle-orm/sqlite-core'
+
+export const users = sqliteTable('users', {
+  id: integer('id').primaryKey({ autoIncrement: true }),
+  email: text('email').notNull().unique(),
+  name: text('name').notNull(),
+  createdAt: integer('created_at', { mode: 'timestamp' })
+    .notNull()
+    .$defaultFn(() => new Date()),
+})
+
+export type User = typeof users.$inferSelect
+export type NewUser = typeof users.$inferInsert
+```
+
+## 3. Querying Patterns
+
+### Inserts and Returning
+
+```typescript
+const result = await db
+  .insert(users)
+  .values({ email: 'test@example.com', name: 'Test' })
+  .returning() // Supported in D1
+```
+
+### Relational Queries (Read-Heavy)
+
+Ensure you define relations in your schema file:
+
+```typescript
+export const usersRelations = relations(users, ({ many }) => ({
+  posts: many(posts),
+}))
+```
+
+Fetch deeply nested data easily:
+
+```typescript
+const userWithPosts = await db.query.users.findFirst({
+  where: eq(users.id, 1),
+  with: {
+    posts: true,
+  },
+})
+```
+
+## 4. Migrations (Cloudflare D1)
+
+Always generate migrations locally and apply them via Wrangler. Never execute `db.execute()` with raw migration SQL at runtime.
+
+1. Generate: `npx drizzle-kit generate`
+2. Apply Locally: `npx wrangler d1 migrations apply my-db --local`
+3. Apply Remote: `npx wrangler d1 migrations apply my-db --remote`
+
+## 5. Security & Safety
+
+- **SQL Injection**: Drizzle is inherently safe against SQL injection as long as you use its builder functions (`eq()`, `like()`, `insert()`). Do not use `sql\`\`` with raw unescaped input.
+- **Transactions**: Use `db.transaction()` for multi-step operations to ensure data integrity.
+- **Migration Commits**: Always commit the generated `.sql` migration files to version control.

package/skills/durable-objects/SKILL.md

@@ -0,0 +1,167 @@
+---
+name: durable-objects
+description: Create and review Cloudflare Durable Objects. Use when building stateful coordination (chat rooms, multiplayer games, booking systems), implementing RPC methods, SQLite storage, alarms, WebSockets, or reviewing DO code for best practices. Covers Workers integration, wrangler config, and testing with Vitest.
+---
+
+# Durable Objects
+
+Build stateful, coordinated applications on Cloudflare's edge using Durable Objects.
+
+## Retrieval-First Development
+
+**Prefer retrieval from official docs over pre-training for Durable Objects tasks.**
+
+| Resource       | URL                                                               |
+| -------------- | ----------------------------------------------------------------- |
+| Docs           | https://developers.cloudflare.com/durable-objects/                |
+| API Reference  | https://developers.cloudflare.com/durable-objects/api/            |
+| Best Practices | https://developers.cloudflare.com/durable-objects/best-practices/ |
+| Examples       | https://developers.cloudflare.com/durable-objects/examples/       |
+
+Fetch the relevant doc page when implementing features.
+
+## When to Use
+
+- Creating new Durable Object classes for stateful coordination
+- Implementing RPC methods, alarms, or WebSocket handlers
+- Reviewing existing DO code for best practices
+- Configuring wrangler.jsonc/toml for DO bindings and migrations
+- Writing tests with `@cloudflare/vitest-pool-workers`
+- Designing sharding strategies and parent-child relationships
+
+## Reference Documentation
+
+- `./references/rules.md` - Core rules, storage, concurrency, RPC, alarms
+- `./references/testing.md` - Vitest setup, unit/integration tests, alarm testing
+- `./references/workers.md` - Workers handlers, types, wrangler config, observability
+
+Search: `blockConcurrencyWhile`, `idFromName`, `getByName`, `setAlarm`, `sql.exec`
+
+## Core Principles
+
+### Use Durable Objects For
+
+| Need                      | Example                                           |
+| ------------------------- | ------------------------------------------------- |
+| Coordination              | Chat rooms, multiplayer games, collaborative docs |
+| Strong consistency        | Inventory, booking systems, turn-based games      |
+| Per-entity storage        | Multi-tenant SaaS, per-user data                  |
+| Persistent connections    | WebSockets, real-time notifications               |
+| Scheduled work per entity | Subscription renewals, game timeouts              |
+
+### Do NOT Use For
+
+- Stateless request handling (use plain Workers)
+- Maximum global distribution needs
+- High fan-out independent requests
+
+## Quick Reference
+
+### Wrangler Configuration
+
+```jsonc
+// wrangler.jsonc
+{
+  "durable_objects": {
+    "bindings": [{ "name": "MY_DO", "class_name": "MyDurableObject" }],
+  },
+  "migrations": [{ "tag": "v1", "new_sqlite_classes": ["MyDurableObject"] }],
+}
+```
+
+### Basic Durable Object Pattern
+
+```typescript
+import { DurableObject } from 'cloudflare:workers'
+
+export interface Env {
+  MY_DO: DurableObjectNamespace<MyDurableObject>
+}
+
+export class MyDurableObject extends DurableObject<Env> {
+  constructor(ctx: DurableObjectState, env: Env) {
+    super(ctx, env)
+    ctx.blockConcurrencyWhile(async () => {
+      this.ctx.storage.sql.exec(`
+        CREATE TABLE IF NOT EXISTS items (
+          id INTEGER PRIMARY KEY AUTOINCREMENT,
+          data TEXT NOT NULL
+        )
+      `)
+    })
+  }
+
+  async addItem(data: string): Promise<number> {
+    const result = this.ctx.storage.sql.exec<{ id: number }>(
+      'INSERT INTO items (data) VALUES (?) RETURNING id',
+      data
+    )
+    return result.one().id
+  }
+}
+
+export default {
+  async fetch(request: Request, env: Env): Promise<Response> {
+    const stub = env.MY_DO.getByName('my-instance')
+    const id = await stub.addItem('hello')
+    return Response.json({ id })
+  },
+}
+```
+
+## Critical Rules
+
+1. **Model around coordination atoms** - One DO per chat room/game/user, not one global DO
+2. **Use `getByName()` for deterministic routing** - Same input = same DO instance
+3. **Use SQLite storage** - Configure `new_sqlite_classes` in migrations
+4. **Initialize in constructor** - Use `blockConcurrencyWhile()` for schema setup only
+5. **Use RPC methods** - Use RPC for DO-to-DO communication (compatibility date >= 2024-04-03). The outer Worker can still use the standard `fetch()` handler to route to the DO stub.
+6. **Persist first, cache second** - Always write to storage before updating in-memory state
+7. **One alarm per DO** - `setAlarm()` replaces any existing alarm
+
+## Anti-Patterns (NEVER)
+
+- Single global DO handling all requests (bottleneck)
+- Using `blockConcurrencyWhile()` on every request (kills throughput)
+- Storing critical state only in memory (lost on eviction/crash)
+- Using `await` between related storage writes (breaks atomicity)
+- Holding `blockConcurrencyWhile()` across `fetch()` or external I/O
+
+## Stub Creation
+
+```typescript
+// Deterministic - preferred for most cases
+const stub = env.MY_DO.getByName('room-123')
+
+// From existing ID string
+const id = env.MY_DO.idFromString(storedIdString)
+const stub = env.MY_DO.get(id)
+
+// New unique ID - store mapping externally
+const id = env.MY_DO.newUniqueId()
+const stub = env.MY_DO.get(id)
+```
+
+## Advanced Features
+
+See [references/advanced_features.md](references/advanced_features.md) for detailed examples of Storage Operations (SQL and KV) and Alarms scheduling.
+
+## Security
+
+- **RPC Access Control**: RPC methods are public to any caller with a stub. Implement authorization inside the method body (e.g., check `this.env.AUTH_TOKEN`).
+- **WebSockets**: Validate WebSocket origin in `onConnect()` to prevent cross-site hijacking.
+
+## Testing Quick Start
+
+```typescript
+import { env } from 'cloudflare:test'
+import { describe, it, expect } from 'vitest'
+
+describe('MyDO', () => {
+  it('should work', async () => {
+    const stub = env.MY_DO.getByName('test')
+    const result = await stub.addItem('test')
+    expect(result).toBe(1)
+  })
+})
+```

package/skills/durable-objects/references/advanced_features.md

@@ -0,0 +1,29 @@
+# Advanced Durable Object Features
+
+## Storage Operations
+
+```typescript
+// SQL (synchronous, recommended)
+this.ctx.storage.sql.exec('INSERT INTO t (c) VALUES (?)', value)
+const rows = this.ctx.storage.sql.exec<Row>('SELECT * FROM t').toArray()
+
+// KV (async)
+await this.ctx.storage.put('key', value)
+const val = await this.ctx.storage.get<Type>('key')
+```
+
+## Alarms
+
+```typescript
+// Schedule (replaces existing)
+await this.ctx.storage.setAlarm(Date.now() + 60_000);
+
+// Handler
+async alarm(): Promise<void> {
+  // Process scheduled work
+  // Optionally reschedule: await this.ctx.storage.setAlarm(...)
+}
+
+// Cancel
+await this.ctx.storage.deleteAlarm();
+```