LazyQoder v1.3.4

LazyQoder v1.3.4 — safer runs, clearer host boundaries

A small maintenance release for the LazySeries family. It repairs runtime and
host-adapter boundaries while retaining the workflow foundation inherited from
family versions v1.3.0–v1.3.3. Those inherited features are not new in this patch
and do not imply prior public releases of the Kimi or DeepSeek ports.

Eval-driven fixes

• Task claims and iteration updates share one transaction; blocked or exhausted queues cannot report completion.
• Repeated run creation preserves history, and stale snapshot commits cannot overwrite intervening plan edits.
• MCP tools return standard content envelopes and reject malformed arguments without terminating the server.
• Finalization requires all intended tasks done; persisted status is assessed
  separately from completion evidence.

Cumulative workflow experience

Describe work in natural language or use explicit workflow entry points.
Keep editable Markdown plans, durable decisions, evidence-bound completion
and verification sized to the change. Planning-only requests remain separate
from execution authority. The README presents these inherited features together
with the 1.3.4 fixes; the repository release history retains the version-by-version record.

Measured efficiency

No new latency, token-saving, cost or recall improvement is measured for this
patch. Ledger append/compaction, learned routing and shared-core migration are deferred.

Host capability matrix

Fresh native host activation and complete onboarding/offboarding acceptance remain pending. Package tests and release publication do not establish those host observations.

Package and distribution checks do not prove a current native host session.
HOST READINESS: PENDING until loading, command/skill behavior and the expected
MCP connections are observed. The README links the selected host's setup guide.

Migration and upgrade

Use the receipt-aware upgrade route with an explicit project binding. Preserve project evidence and unknown host configuration. No credentials or production host settings are changed by package verification.

Read AGENTS.md and the install guide.
Choose one route, check the installed package version, and restart the host.
Source checkouts and release archives have different build requirements; follow
the documented route. Do not reset populated runs merely to upgrade.

Known risks

Native acceptance is separate from package readiness. Token/cost budgets are
metadata; pending approvals are persisted observations without a live approval
queue. Shell loop policy beyond the configured global cap needs orchestrator enforcement.

Rollback

Retain the published v1.3.3 tag and ownership receipts. Remove only receipt-owned, unmodified assets and use a fresh host session to verify removal.

Documentation and family presentation

Aligned sibling README structure, current setup navigation and a shared six-repo
family table. Personal environment files and caches are ignored while example
configuration and pinned fixtures remain publishable. Earlier release notes
remain in the repository release history.

Documentation follow-ups are available on main; the published v1.3.4
archive retains its original verified tag source.

Post-publication repository maintenance

The current main-branch dependency lock uses patched fast-uri 3.1.8.
This addresses host canonicalization.
Existing published v1.3.4 archives retain their original tagged dependency
contents. Use the current source lock for this fix; a refreshed archive needs
a subsequent versioned release.