wotann 0.5.0

package/skills/cpp-pro.md

@@ -0,0 +1,72 @@
+---
+name: cpp-pro
+description: Modern C++20/23 with RAII, concepts, ranges, and zero-cost abstractions
+context: fork
+paths: ["**/*.cpp", "**/*.h", "**/*.hpp", "**/CMakeLists.txt"]
+requires:
+  bins: ["g++"]
+---
+
+# C++ Pro
+
+## When to Use
+
+- Writing high-performance native modules for WOTANN (e.g., SQLite FTS5 extensions).
+- Integrating Computer-Use perception engines that need SIMD or raw memory control.
+- Reviewing legacy C++03/11 code for modernization to C++20/23.
+- Designing header-only libraries with concepts and templates.
+- Debugging UB, lifetime, or template instantiation issues.
+
+## Rules
+
+- C++20 minimum; prefer C++23 (`std::expected`, `std::print`, deducing this).
+- RAII on every resource; never manual new/delete, never raw `malloc`/`free`.
+- Smart pointers: `unique_ptr` by default, `shared_ptr` only for shared ownership.
+- No C-style casts (`(T)x`) — use `static_cast`, `const_cast`, `reinterpret_cast`.
+- `const` everywhere by default; add mutability only when required.
+- Enable `-Wall -Wextra -Wpedantic -Werror` and sanitizers in CI.
+
+## Patterns
+
+- **Concepts over SFINAE**: `template<std::integral T>` is readable and diagnostic-friendly.
+- **Ranges/views**: compose lazy pipelines (`std::views::filter | transform | take`).
+- **std::expected**: typed errors without exceptions (`std::expected<T, Error>`).
+- **Move semantics**: `&&` parameters, `std::move`, rule of zero.
+- **Modules**: `import std;` replaces monolithic headers where toolchain supports it.
+
+## Example
+
+```cpp
+#include <expected>
+#include <ranges>
+#include <string>
+
+struct ParseError { std::string what; };
+
+std::expected<int, ParseError> parseInt(std::string_view s) {
+    int value{};
+    auto [ptr, ec] = std::from_chars(s.data(), s.data() + s.size(), value);
+    if (ec != std::errc{}) return std::unexpected(ParseError{"not a number"});
+    return value;
+}
+
+auto sumValid(std::span<std::string_view> tokens) {
+    return tokens
+        | std::views::transform(parseInt)
+        | std::views::filter([](auto& r) { return r.has_value(); })
+        | std::views::transform([](auto& r) { return *r; });
+}
+```
+
+## Checklist
+
+- [ ] No raw new/delete in changed files.
+- [ ] All resource owners use RAII or smart pointers.
+- [ ] `-Wall -Wextra -Wpedantic -Werror` clean, UBSan/ASan enabled in CI.
+- [ ] No C-style casts; all casts named and scoped.
+
+## Common Pitfalls
+
+- `shared_ptr` cycles leak memory; break with `weak_ptr` on back-pointers.
+- Relying on copy elision that the spec doesn't mandate; write moves explicitly.
+- Using `std::optional<T&>` (not allowed) — use `T*` or `std::reference_wrapper`.

package/skills/csharp-developer.md

@@ -0,0 +1,70 @@
+---
+name: csharp-developer
+description: .NET 8+, minimal APIs, Blazor, Entity Framework with modern C# 12 features
+context: fork
+paths: ["**/*.cs", "**/*.csproj"]
+requires:
+  bins: ["dotnet"]
+---
+
+# C# Developer
+
+## When to Use
+
+- Building a new .NET 8+ service with minimal APIs or controllers.
+- Designing a Blazor Server or WebAssembly app with component composition.
+- Writing Entity Framework Core migrations and repository-style data access.
+- Migrating older ASP.NET Framework code to modern ASP.NET Core.
+- Adding OpenAPI/Swagger, health checks, and structured logging to a service.
+
+## Rules
+
+- .NET 8+ and C# 12 features only (primary constructors, collection expressions).
+- Nullable reference types enabled (`<Nullable>enable</Nullable>`) project-wide.
+- `async/await` throughout; never `.Result` or `.Wait()` (deadlocks UI threads).
+- Use `record` for DTOs and immutable value objects.
+- DI via `builder.Services`; never `new` a service inside a controller.
+- Every public API surface has XML doc comments consumed by OpenAPI.
+
+## Patterns
+
+- **Minimal APIs** for lightweight services; MVC Controllers for complex routing.
+- **Options pattern**: `IOptionsSnapshot<T>` for runtime-refreshable config.
+- **Mediator (MediatR)**: thin controllers dispatching to request handlers.
+- **EF Core**: migrations via `dotnet ef migrations add`, no DB-first unless forced.
+- **Problem Details**: RFC 7807 error body via `builder.Services.AddProblemDetails()`.
+
+## Example
+
+```csharp
+var builder = WebApplication.CreateBuilder(args);
+builder.Services.AddDbContext<AppDb>(o => o.UseNpgsql(builder.Configuration.GetConnectionString("Db")));
+
+var app = builder.Build();
+
+app.MapGet("/users/{id:guid}", async (Guid id, AppDb db, CancellationToken ct) =>
+{
+    var user = await db.Users.FindAsync([id], ct);
+    return user is null ? Results.NotFound() : Results.Ok(UserDto.From(user));
+});
+
+public sealed record UserDto(Guid Id, string Email)
+{
+    public static UserDto From(User u) => new(u.Id, u.Email);
+}
+
+app.Run();
+```
+
+## Checklist
+
+- [ ] Nullable reference types enabled at project level.
+- [ ] No `.Result`/`.Wait()` in async chains.
+- [ ] Records used for DTOs and value objects.
+- [ ] EF migrations generated and applied; no pending model diff.
+
+## Common Pitfalls
+
+- `async void` outside event handlers swallows exceptions; use `async Task`.
+- Forgetting `CancellationToken` plumbing — long-running requests can't be cancelled.
+- Capturing `DbContext` in a singleton; DbContexts must be scoped.

package/skills/debug-hypothesis-tree.md

@@ -0,0 +1,56 @@
+---
+name: debug-hypothesis-tree
+description: Multi-hypothesis breadth-first tree debugging. Generates 3-5 distinct hypotheses for a bug, expands each one node deeper before committing to a path, and prunes branches as evidence accumulates. Use when a bug has multiple plausible causes and you don't yet know which is correct.
+type: workflow
+---
+
+# Debug Hypothesis Tree — Breadth-First Causal Search
+
+When you cannot tell which of several causes is responsible, the wrong move is to commit to one and dig. The right move is to expand all of them one level — then prune.
+
+## When to invoke
+
+- A test fails for the first time and you have 3+ plausible causes.
+- A production bug surfaces and the symptom is consistent with multiple subsystems.
+- You have already tried one hypothesis and it dead-ended.
+
+## When NOT to invoke
+
+- You have a single high-probability hypothesis. Use `superpowers:systematic-debugging` instead.
+- The bug is already reproduced and isolated to one function. Skip straight to the fix.
+
+## Procedure
+
+### Step 1: enumerate
+List 3 to 5 hypotheses. Each must be specific enough to test in less than 10 minutes. "Maybe the database is wrong" is not specific. "The migration ran on staging but not on prod" is.
+
+### Step 2: rank by likelihood
+Use prior knowledge. The cheap-to-test hypothesis often beats the most-likely hypothesis — try the cheap ones first.
+
+### Step 3: expand one level
+For EACH hypothesis, write down ONE concrete check that would either confirm or refute it. Run all the checks before committing to a single path. A check that takes more than 10 minutes is too big — break it down.
+
+### Step 4: prune
+After running the checks, mark each hypothesis as:
+- CONFIRMED — go to step 5.
+- REFUTED — drop the branch.
+- INCONCLUSIVE — schedule a deeper check.
+
+If 0 are CONFIRMED, expand the INCONCLUSIVE branches one more level.
+
+### Step 5: dig into the confirmed branch
+Now use systematic-debugging on the confirmed hypothesis.
+
+## What to write down
+
+For each hypothesis, record:
+1. Statement (one sentence, falsifiable).
+2. Check (concrete command or observation).
+3. Result (CONFIRMED / REFUTED / INCONCLUSIVE).
+4. Evidence (output, line number, screenshot reference).
+
+Keep this in `findings.md` so the next session can pick it up.
+
+## Cap
+
+If you expand to 3 levels with no CONFIRMED hypothesis, STOP. The bug is more complex than this skill's mental model. Hand off to `tree-search` (agentic BFTS) or escalate.

package/skills/dependency-auditor.md

@@ -0,0 +1,50 @@
+---
+name: dependency-auditor
+description: CVE scanning, supply-chain security, SBOM, license compliance
+context: fork
+paths: ["**/package.json", "**/Cargo.toml", "**/go.mod", "**/requirements.txt", "**/pyproject.toml", "**/Gemfile", "**/pom.xml"]
+---
+
+# Dependency Auditor
+
+## When to Use
+- Reviewing third-party deps before adding or upgrading.
+- Responding to a CVE advisory (GitHub, OSV, NVD, Snyk).
+- Generating a Software Bill of Materials for compliance.
+- License review before product ship.
+- Pre-release gate on new vulnerabilities.
+
+## Rules
+- Pin direct deps to exact versions; the lockfile pins transitives.
+- Run `npm audit --production` / `pip-audit` / `cargo audit` / `govulncheck` on every PR.
+- Treat CRITICAL or HIGH CVEs on runtime deps as release blockers.
+- Track abandoned / deprecated packages — silent supply-chain risks.
+- Ship a CycloneDX or SPDX SBOM with every binary release.
+
+## Patterns
+- **Pre-commit hook** running a fast audit with cached results.
+- **Weekly CI job** with deep scan (Snyk, Trivy, Grype).
+- **Dependabot / Renovate** for auto-PR patch upgrades.
+- **License allow-list** (MIT, Apache-2.0, BSD, ISC); block strong copyleft unless project is compatible.
+- **Vendoring** critical deps for reproducible, offline builds.
+
+## Example
+```bash
+# Generate SBOM and fail build on HIGH+ severity.
+npx @cyclonedx/cyclonedx-npm --output-file sbom.json
+npx grype sbom:sbom.json --fail-on high
+```
+
+## Checklist
+- [ ] No HIGH/CRITICAL CVEs on runtime deps.
+- [ ] Lockfile committed and is the source of truth.
+- [ ] SBOM generated and attached to each release.
+- [ ] License report reviewed; no incompatible copyleft.
+- [ ] Abandoned packages flagged and tracked (last commit > 18 months).
+
+## Common Pitfalls
+- **Running audit locally only** misses prod-only deps.
+- **Ignoring transitive advisories** because the direct dep is fine.
+- **"No known fix"** advisories still need mitigations (isolation, patching).
+- **License ambiguity** (UNLICENSED, custom, proprietary) slipping through.
+- **Pinning to `latest`** in Docker images — non-reproducible rebuilds.

package/skills/design-doc-template.md

@@ -0,0 +1,82 @@
+---
+name: design-doc-template
+description: Lightweight design-doc template for non-trivial features and architecture changes. Eight sections - context, goals, non-goals, alternatives, decision, risks, rollout, open questions. Use when a change is large enough that getting the API wrong is expensive.
+type: template
+---
+
+# Design Doc Template
+
+A design doc is the cheapest way to surface alignment problems before you write code. It is NOT a spec, NOT a PRD, NOT a postmortem. It is a "here is what I am about to build and why" memo aimed at your future self and any reviewer.
+
+## When to use
+
+- Multi-week feature work.
+- Cross-team API or schema change.
+- Architecture choice with hard-to-reverse consequences (database engine, message bus, serialization format).
+
+## When NOT to use
+
+- One-line config changes.
+- Bug fixes.
+- Refactors with no public-API impact.
+
+## Template
+
+```markdown
+# [Title — verb + noun, e.g. "Add per-user rate limit"]
+
+Author: [name]
+Date: [YYYY-MM-DD]
+Status: draft / in-review / accepted / superseded
+Reviewers: [names]
+
+## 1. Context
+
+What system are we changing? What does it do today? Two paragraphs max.
+A reader who has never seen the codebase should be able to follow.
+
+## 2. Goals
+
+Bulleted, measurable. "Reduce p99 from 800ms to 200ms" — not "improve performance".
+
+## 3. Non-goals
+
+Explicit list of things this work does NOT do. Saves review cycles.
+
+## 4. Alternatives considered
+
+For each alternative:
+- Sketch (one paragraph).
+- Why it was not chosen.
+
+Two alternatives minimum. "Do nothing" is always an alternative — say why it loses.
+
+## 5. Decision
+
+The chosen design. Include:
+- Public API / schema sketch (signatures, not implementation).
+- Sequence diagram if multiple actors are involved.
+- Storage model if data shape changes.
+
+## 6. Risks
+
+What could go wrong? Three rows minimum.
+| Risk | Likelihood | Mitigation |
+|------|------------|------------|
+
+## 7. Rollout
+
+How will this ship? Behind a flag? Migration plan? Backout plan?
+
+## 8. Open questions
+
+Anything you have not resolved yet. Reviewers expect to see this filled.
+```
+
+## How to review one
+
+For each section, ask: "could a reasonable person disagree with this and we just don't know?" If yes, that section needs more clarity.
+
+If section 4 has only one alternative, send the doc back. The author has not actually decided — they have just written down what they were going to do anyway.
+
+If section 6 has zero risks, the author is overconfident. Even trivial changes have risks.

package/skills/django-expert.md

@@ -0,0 +1,66 @@
+---
+name: django-expert
+description: Django 5+, DRF, ORM, admin, migrations, async views
+context: fork
+paths: ["**/django*", "**/manage.py", "**/settings.py", "**/*/models.py", "**/*/views.py"]
+requires:
+  bins: ["python3"]
+---
+
+# Django Expert
+
+## When to Use
+- Building or reviewing a Django app or DRF API.
+- Designing models, migrations, or queryset managers.
+- Choosing between class-based views, function views, or DRF viewsets.
+- Debugging N+1 queries, slow admin, or migration drift.
+- Adding async views, Channels, or celery tasks.
+
+## Rules
+- Use Django REST Framework for APIs; do not hand-roll JSON responses.
+- Put query logic in model managers and custom querysets — keep views thin.
+- Every new model change is a migration; never edit migrations post-merge.
+- Use `select_related` and `prefetch_related` to avoid N+1 queries.
+- Use signals sparingly — they're magic; prefer explicit calls.
+- Admin is for staff, not for users — don't expose it externally without protection.
+
+## Patterns
+- **Fat models, thin views, smart managers.**
+- **Serializer composition** (nested, writable, read-only) for DRF endpoints.
+- **Permissions classes** and **throttling** for auth and rate limiting.
+- **`prefetch_related` with `Prefetch`** for selective subquery optimization.
+- **Async views** for I/O-bound endpoints (`async def` + ASGI server).
+- **Celery + Redis** for background tasks, retries, and scheduled jobs.
+
+## Example
+```py
+# Fat manager keeps views clean and testable.
+class ActiveOrderManager(models.Manager):
+    def pending(self):
+        return self.filter(status="pending").select_related("user")
+
+class Order(models.Model):
+    status = models.CharField(max_length=32)
+    user = models.ForeignKey(User, on_delete=models.CASCADE)
+    objects = models.Manager()
+    active = ActiveOrderManager()
+
+# View is one line.
+class PendingOrders(ListAPIView):
+    queryset = Order.active.pending()
+    serializer_class = OrderSerializer
+```
+
+## Checklist
+- [ ] Views are thin; business logic in models / managers / services.
+- [ ] `select_related` / `prefetch_related` cover all FK traversals in hot paths.
+- [ ] Every migration is atomic (or marked non-atomic intentionally).
+- [ ] Admin protected by an internal network or MFA.
+- [ ] `DEBUG = False` + `ALLOWED_HOSTS` in production settings.
+
+## Common Pitfalls
+- **N+1 queries in templates** — `.prefetch_related` fixes most of it.
+- **Editing a shipped migration** — breaks replicas and rollbacks.
+- **Signals doing heavy work synchronously** — move to Celery.
+- **Using `.objects.all()` for admin lists** on huge tables.
+- **Leaking `SECRET_KEY`** into repo settings.

package/skills/docker-expert.md

@@ -0,0 +1,41 @@
+---
+name: docker-expert
+description: Multi-stage builds, image optimization, container security
+context: fork
+paths: ["**/Dockerfile*", "**/docker-compose*", "**/.dockerignore"]
+requires:
+  bins: ["docker"]
+---
+
+# Docker Expert
+
+## Multi-Stage Builds
+Always use multi-stage builds to minimize final image size:
+```dockerfile
+FROM node:20-alpine AS builder
+WORKDIR /app
+COPY package*.json ./
+RUN npm ci --production=false
+COPY . .
+RUN npm run build
+
+FROM node:20-alpine AS runner
+WORKDIR /app
+COPY --from=builder /app/dist ./dist
+COPY --from=builder /app/node_modules ./node_modules
+USER node
+CMD ["node", "dist/index.js"]
+```
+
+## Security
+- Never run as root (use `USER node` or `USER 1000`).
+- Use `.dockerignore` to exclude secrets, .git, node_modules.
+- Pin base image versions (not `latest`).
+- Use `--no-install-recommends` for apt.
+- Scan images with `docker scout` or `trivy`.
+
+## Optimization
+- Order layers by change frequency (dependencies first, code last).
+- Use alpine base images when possible.
+- Combine RUN commands to reduce layers.
+- Use COPY instead of ADD (unless extracting archives).

package/skills/documentation.md

@@ -0,0 +1,65 @@
+---
+name: documentation
+description: Technical writing, API docs, ADRs, READMEs, runbooks
+context: fork
+paths: ["**/*.md", "**/docs/**", "**/README*"]
+---
+
+# Documentation
+
+## When to Use
+- Writing or updating a README, getting-started guide, or tutorial.
+- Authoring an ADR (Architectural Decision Record) for a meaningful choice.
+- Producing reference docs from code (JSDoc, TSDoc, Sphinx, Rustdoc).
+- Creating a runbook for an on-call incident pattern.
+- Reviewing docs for clarity, accuracy, and freshness.
+
+## Rules
+- Write for the reader who knows nothing about the project.
+- Lead with the "why" before the "how".
+- Every code block must be runnable, copyable, and self-contained.
+- Prefer a diagram when words would take more than three paragraphs.
+- Stale docs are worse than no docs — if you can't maintain it, don't write it.
+- Link, don't duplicate — one source of truth per fact.
+
+## Patterns
+- **Diataxis framework**: Tutorials, How-to guides, Reference, Explanation.
+- **ADR**: Title, Status, Context, Decision, Consequences, Alternatives.
+- **Runbook**: Symptom → Diagnosis → Mitigation → Root cause → Owner.
+- **README spine**: Elevator pitch → Quickstart → Install → Usage → Links.
+- **Inline docstrings** with typed examples that double as doctests.
+
+## Example
+```markdown
+# Installing WOTANN
+
+> One-liner of what you get.
+
+## Prerequisites
+- Node 20+
+- An API key from any provider (optional for local-only mode)
+
+## Install
+```bash
+npm i -g wotann
+wotann init
+```
+
+## Next
+- [Quickstart tutorial](./tutorial.md)
+- [Configuration reference](./reference/config.md)
+```
+
+## Checklist
+- [ ] A first-time reader can finish the quickstart in under five minutes.
+- [ ] Code blocks include language tags for syntax highlighting.
+- [ ] Every link works — no 404s, no stale URLs.
+- [ ] Docs live next to the code they describe when possible.
+- [ ] Breaking changes trigger a doc update in the same PR.
+
+## Common Pitfalls
+- **Reference material where tutorials belong** — learners bounce.
+- **"Simply" and "just"** — words that gaslight readers.
+- **Untested code samples** that drift from the API they describe.
+- **Overloaded READMEs** being tutorial + reference + changelog.
+- **Undated content** so readers can't tell what's current.

package/skills/dotnet-core.md

@@ -0,0 +1,69 @@
+---
+name: dotnet-core
+description: .NET 8, minimal APIs, Entity Framework Core, Blazor, ASP.NET Core
+context: fork
+paths: ["**/*.csproj", "**/Program.cs", "**/*.cs"]
+requires:
+  bins: ["dotnet"]
+---
+
+# .NET Core
+
+## When to Use
+- Building or reviewing a .NET 8+ application (API, Blazor, worker, console).
+- Designing minimal APIs or converting controllers to minimal APIs.
+- EF Core model / migration / query-performance work.
+- Implementing CQRS with MediatR or source-generated alternatives.
+- Diagnosing allocations, GC pressure, or async-deadlock bugs.
+
+## Rules
+- Nullable reference types enabled project-wide; `<Nullable>enable</Nullable>`.
+- Use minimal APIs for simple endpoints; controllers only when model binding or filters justify.
+- Return `IResult` / `Results.*` from minimal endpoints for typed responses.
+- Use `async`/`await` all the way; never `.Result` or `.Wait()` on async code.
+- Use `record` types for DTOs and value objects; keep them immutable.
+- EF Core: `AsNoTracking()` for reads; explicit `Include`/`ThenInclude` over lazy loading.
+
+## Patterns
+- **Vertical slice architecture** — each feature is a folder with its request, handler, validator, endpoint.
+- **MediatR** (or source-gen) for CQRS — request → handler.
+- **FluentValidation** for input validation.
+- **Output caching + response compression** for static-ish endpoints.
+- **Health checks** with `AddHealthChecks()` + `/healthz` endpoint.
+- **`IHostedService`** for background jobs; upgrade to Quartz.NET if complex.
+
+## Example
+```csharp
+// Program.cs — minimal API with validation and typed result.
+var builder = WebApplication.CreateBuilder(args);
+builder.Services.AddValidatorsFromAssemblyContaining<Program>();
+builder.Services.AddDbContext<AppDb>(o => o.UseNpgsql(builder.Configuration.GetConnectionString("Db")));
+var app = builder.Build();
+
+app.MapPost("/users", async (CreateUserRequest req, IValidator<CreateUserRequest> v, AppDb db) =>
+{
+    var result = await v.ValidateAsync(req);
+    if (!result.IsValid) return Results.ValidationProblem(result.ToDictionary());
+
+    var user = new User(req.Email);
+    db.Users.Add(user);
+    await db.SaveChangesAsync();
+    return Results.Created($"/users/{user.Id}", user);
+});
+
+app.Run();
+```
+
+## Checklist
+- [ ] Nullable reference types enabled; no `#nullable disable`.
+- [ ] Async all the way down; no `.Result` or `.Wait()`.
+- [ ] EF queries use `AsNoTracking()` where appropriate.
+- [ ] Validation at the edge (FluentValidation or data annotations).
+- [ ] Health check + structured logging + OpenTelemetry wired.
+
+## Common Pitfalls
+- **Sync-over-async** in library code (`.Result`) — deadlocks under load.
+- **Lazy loading** in EF causing N+1 queries without visibility.
+- **DI lifetime mismatch** — scoped service injected into singleton.
+- **Missing `ConfigureAwait(false)`** in library code running in sync contexts.
+- **Over-applying MediatR** to trivial CRUD — boilerplate with no benefit.

package/skills/dream-cycle.md

@@ -0,0 +1,59 @@
+---
+name: dream-cycle
+description: autoDream memory consolidation - WOTANN's nightly learning extraction pipeline
+context: fork
+paths: []
+---
+
+# Dream Cycle (autoDream)
+
+## When to Use
+
+- Nightly or idle periods when WOTANN's Engine daemon has spare CPU.
+- After a heavy session with 20+ new observations that need consolidation.
+- Before a release, to promote proven patterns into durable rules.
+- When `.wotann/learning/observations.jsonl` grows past its soft cap.
+- To decay stale observations that no longer reflect current behavior.
+
+## Rules
+
+- Three gates (time, volume, lock) must all pass before a cycle runs.
+- Only one consolidation at a time — the lock gate prevents concurrent cycles.
+- Never destroy raw observations; archive them instead so corrections can re-examine source.
+- Confidence thresholds: <0.3 decay, 0.3-0.7 keep, >=0.7 promote to rule/skill candidate.
+- Pattern promotion requires human review before becoming a shipped skill.
+- Record each cycle's summary to Engram (`topic_key: learning/dreams/<date>`).
+
+## Patterns
+
+- **Three-gate trigger**: (1) time >= 4h since last, (2) >= 20 new observations, (3) lock free.
+- **Four phases**: Collect -> Classify -> Consolidate -> Promote.
+- **Classification bins**: correction, confirmation, discovery, pattern.
+- **Decay curve**: linear confidence drop per week of inactivity; floor at 0.
+- **Promotion pipeline**: high-confidence patterns -> skill candidates -> `superpowers:writing-skills`.
+
+## Example
+
+```
+[2026-04-13 03:14] autoDream cycle start (trigger: time+volume)
+  lock acquired: .wotann/learning/dream.lock
+  phase 1 collect   -> 47 observations since 2026-04-12 23:00
+  phase 2 classify  -> corrections: 6, confirmations: 22, discoveries: 8, patterns: 11
+  phase 3 consolidate -> merged 14 duplicates; confidence recomputed
+  phase 4 promote   -> 3 patterns queued as skill candidates
+  summary saved     -> Engram topic_key=learning/dreams/2026-04-13
+  lock released; next cycle eligible after 2026-04-13 07:14
+```
+
+## Checklist
+
+- [ ] All three gates confirmed passing before starting.
+- [ ] Lock file created and released on exit (even on error).
+- [ ] Raw observations archived, not deleted.
+- [ ] Summary saved to Engram for human review.
+
+## Common Pitfalls
+
+- Forgetting to release the lock on crash; next cycle never runs until manually cleared.
+- Promoting single-session patterns; require the pattern to recur in >=3 sessions.
+- Decaying corrections too aggressively; user feedback must stick longer than tips.