Fix/audit 2026 07

.gitmodules

@@ -1,3 +1,3 @@
 [submodule "wiki"]
 	path = wiki
-	url = git@github.com:tinyhumansai/tinyagents.wiki.git
+	url = https://github.com/tinyhumansai/tinyagents.wiki.git

AGENTS.md

@@ -3,10 +3,12 @@
 ## Project Structure & Module Organization
 
 TinyAgents is a Rust 2024 library crate rooted at `Cargo.toml`. Public API
-exports live in `src/lib.rs`, with core modules split across `src/chat.rs`,
-`src/model.rs`, `src/tool.rs`, `src/graph.rs`, and `src/error.rs`. Additional
-architecture work is staged under module directories such as `src/harness/`,
-`src/language/`, and `src/registry/`.
+exports live in `src/lib.rs`, with the crate-wide error type in `src/error.rs`.
+The five surfaces each live in their own module directory: `src/graph/`
+(durable typed state graphs), `src/harness/` (provider-neutral model calls,
+tools, middleware, streaming), `src/language/` (the declarative `.rag`
+blueprint format), `src/registry/` (the named capability catalog), and
+`src/repl/` (the imperative `.ragsh` session runtime).
 
 Prefer small, focused modules that do one thing extremely well. New feature
 areas should live in module directories instead of accumulating broad,
@@ -15,10 +17,22 @@ dedicated `types.rs` file and keep module-local unit tests in a dedicated
 `test.rs` file. The module root should wire the pieces together and expose the
 smallest useful API.
 
-Integration tests are in `tests/`, currently focused on serialization behavior.
-Runnable usage examples are in `examples/`, especially
-`examples/basic_graph.rs`. Design notes and module-level specifications live in
-`docs/`, with `docs/spec/README.md` as the top-level architecture reference.
+Two Cargo features gate optional dependencies: `sqlite` (embedded SQLite
+checkpointer, `graph::checkpoint::SqliteCheckpointer`) and `repl` (embedded
+Rhai engine backing `repl::session`); every other provider and surface is
+compiled in by default.
+
+Integration tests are in `tests/`, covering serialization, graph routing,
+registry binding, the expressive and REPL languages, streaming, subagents,
+and provider contracts (including live, network-gated tests such as
+`tests/live_*.rs`). Runnable usage examples are in `examples/`, especially
+`examples/basic_graph.rs`. Design notes and module-level specifications live
+in `docs/`, with `docs/spec/README.md` as the top-level architecture
+reference and `docs/modules/` holding per-surface design docs (`graph/`,
+`harness/`, `registry/`, `expressive-language/`, `repl-language/`). A `wiki/`
+git submodule holds the published GitHub wiki pages; do not edit it as part
+of unrelated work, and commit its pointer update separately when it does
+change.
 
 ## Build, Test, and Development Commands
 

CONTRIBUTING.md

@@ -20,6 +20,31 @@ The bundled example should also run:
 cargo run --example basic_graph
 ```
 
+To build with the optional embedded SQLite checkpointer or the `.ragsh` Rhai
+session runtime, enable the relevant feature:
+
+```sh
+cargo test --features sqlite
+cargo test --features repl
+```
+
+### Wiki Submodule
+
+The published GitHub wiki lives in `wiki/`, checked out as a git submodule
+pointing at the `tinyhumansai/tinyagents.wiki` repository. It is not part of
+the crate build and is not covered by this project's Markdown line-length or
+review rules. Clone with submodules to pull it down:
+
+```sh
+git clone --recurse-submodules https://github.com/tinyhumansai/tinyagents.git
+# or, in an existing checkout:
+git submodule update --init wiki
+```
+
+Do not edit `wiki/` content as part of an unrelated code or docs change; wiki
+edits should be their own commit (or made directly on the wiki) so the
+submodule pointer update stays easy to review in isolation.
+
 ## Project Philosophy
 
 TinyAgents should make agent systems explicit and inspectable. Prefer:

README.md

@@ -157,21 +157,23 @@ Add TinyAgents to your project:
 
 ```toml
 [dependencies]
-tinyagents = "0.1"
+tinyagents = "1.5"
 ```
 
-The OpenAI (and OpenAI-compatible) provider is compiled in by default and pulls
-no extra dependencies; the build stays offline unless you actually make a call.
+The OpenAI (and OpenAI-compatible) provider is compiled in by default; the
+build stays offline unless you actually make a call. Two optional Cargo
+features gate heavier dependencies: `sqlite` (embedded SQLite checkpointer)
+and `repl` (embedded Rhai engine for the `.ragsh` session runtime).
 
 To explore locally:
 
 ```sh
-git clone git@github.com:tinyhumansai/rustagents.git
-cd rustagents
+git clone git@github.com:tinyhumansai/tinyagents.git
+cd tinyagents
 cargo run --example basic_graph
 ```
 
-OpenAI-backed examples need the feature flag and an API key:
+OpenAI-backed examples need an API key:
 
 ```sh
 export OPENAI_API_KEY=...
@@ -236,6 +238,10 @@ All live in [`examples/`](examples/):
 - **`openai_self_blueprint`** — **the deepest recursion:** a model authors a
   `.rag` blueprint that is compiled and run on the same runtime.
 - **`rag_blueprint`** — load and run a declarative `.rag` workflow.
+- **`goals_and_todos`** — a durable `ThreadGoal` driving a `TaskBoard` kanban
+  on one thread.
+- **`subconscious_loop`** — an offline, testable autonomous closed-loop
+  harness (see [`examples/subconscious_loop/README.md`](examples/subconscious_loop/README.md)).
 - **`openai_chat`** — a single provider-backed chat turn.
 - **`openai_tools`** — tool calling against a hosted model.
 - **`openai_structured`** — typed structured output.

ROADMAP.md

@@ -1,66 +1,50 @@
 # Roadmap
 
-TinyAgents is pre-1.0. The roadmap favors small, well-tested modules that build
-toward a production-grade Rust agent runtime.
-
-## Current Foundation
-
-- chat message primitives
-- model request and response types
-- async chat model trait
-- async tool trait
-- executable state graph
-- direct and conditional routing
-- graph validation and recursion limits
-- basic examples and serialization tests
+TinyAgents is at v1.5.0. The roadmap favors small, well-tested modules that
+build toward a production-grade Rust agent runtime.
+
+## Shipped Foundation
+
+- typed harness model calls, tools, middleware, structured output, streaming,
+  usage/cost tracking, retry/limits, cache, memory/embeddings, sub-agents,
+  and steering (`harness/`)
+- durable typed state graph runtime: `START`/`END`, nodes, conditional
+  routing, `Command`s, fan-out, reducers/channels, checkpoints, interrupts,
+  subgraphs, streaming, and topology export (`graph/`)
+- per-thread `ThreadGoal` and `TaskBoard` productivity primitives, exposed as
+  harness tools
+- named capability registry (models, tools, agents, graphs, stores,
+  middleware, policy) bound by name (`registry/`)
+- the declarative `.rag` blueprint language: lexer, parser, compiler, and
+  registry-backed binding (`language/`)
+- the imperative `.ragsh` REPL language for capability-bound interactive
+  orchestration (`repl/`)
+- an optional SQLite-backed checkpointer (`sqlite` feature) and an optional
+  Rhai-backed `.ragsh` session runtime (`repl` feature)
+- an embedded Langfuse client and graph exporter for observability
 
 ## Near-Term Work
 
-- split broad modules into focused module directories with `types.rs` and
-  `test.rs`
-- expand graph tests for routing, recursion, validation, and error behavior
-- strengthen harness model, tool, prompt, context, middleware, and usage APIs
-- add more examples for model calls, tools, and graph composition
-- define reducer and state-channel APIs for parallel writes
-- document stable public API boundaries as modules mature
-
-## Declarative Workflow Language
-
-The `.rag` language should let humans and LLMs describe agent workflows without
-embedding arbitrary host code.
-
-Planned capabilities:
-
-- graph topology declarations
-- allowed models, tools, agents, stores, middleware, and subgraphs
-- state channels and reducers
-- direct routes, conditional routes, commands, sends, joins, and barriers
-- parallel sub-agent fanout
-- blocking and optional child-agent policies
-- checkpoint, interrupt, timeout, retry, budget, and concurrency policies
-- source spans and diagnostics
-- blueprint review before execution
+- broaden `.rag`/`.ragsh` example coverage for less-common routing and
+  parallel-fanout shapes
+- continue splitting any module or doc that grows past the 500-line limit
+  into focused files
+- expand live (network-gated) provider contract tests as new
+  OpenAI-compatible endpoints are added
+- track and close the internal SDK feature-parity backlog in
+  [`docs/sdk-gaps.md`](docs/sdk-gaps.md)
 
 ## Parallel Agents And Sub-Agents
 
-TinyAgents should support workflow-native parallelism:
-
-- forked child contexts
-- shared caches with explicit isolation policy
-- child event namespaces
-- parent and child run ids
-- deterministic reducer-based merges
-- optional, blocking, race, quorum, fallback, and compare policies
-- resumable checkpoints across parallel branches
-
-## REPL And Agent-Authored Workflows
-
-The `.ragsh` REPL layer should let agents and humans inspect, script, and
-control graph runs through capability-bound functions. It should be able to
-propose `.rag` workflows, but those workflows must pass through parser,
-registry, policy, and compiler checks before execution.
+Shipped: forked child contexts, shared caches with explicit isolation policy,
+child event namespaces, parent/child run ids, deterministic reducer-based
+merges, optional/blocking/race/quorum/fallback/compare policies, and
+resumable checkpoints across parallel branches. Ongoing work focuses on
+hardening edge cases surfaced by the `e2e_parallel_*` and `live_subagent_*`
+test suites.
 
-## Pre-1.0 Stability
+## Stability
 
-APIs may change before 1.0. Changes should be documented, tested, and shaped by
-real examples rather than speculative abstraction.
+The public API is versioned via semver starting at 1.0. Breaking changes are
+documented in release notes, tested, and shaped by real examples rather than
+speculative abstraction.

docs/audit.md

@@ -2,7 +2,7 @@
 
 Date: 2026-06-29
 
-This audit reviewed the current RustAgents codebase for correctness gaps,
+This audit reviewed the current TinyAgents codebase for correctness gaps,
 security issues, implementation weaknesses, and spec-contract mismatches. No
 code changes were made as part of the audit.