@lazyingart/agintiflow 0.20.83 → 0.20.84

package/README.md

@@ -256,7 +256,7 @@ Inside chat:
 /aaps dry-run workflows/main.aaps
 ```
 
-Use AAPS when the task is bigger than a single chat: app development with stages, paper/book workflows, validation gates, recovery steps, artifact production, or top-down agentic scripts. The current adapter is intentionally lightweight: prompt-only AAPS tasks are reported as handoffs and do not automatically execute an LLM/backend agent yet, so AgInTiFlow warns when a run has no executable steps or misses a declared output. See [docs/aaps.md](docs/aaps.md) and the package [https://www.npmjs.com/package/@lazyingart/aaps](https://www.npmjs.com/package/@lazyingart/aaps).
+Use AAPS when the task is bigger than a single chat: app development with stages, paper/book workflows, validation gates, recovery steps, artifact production, or top-down agentic scripts. There are two bridge directions: AgInTiFlow can inspect/validate/compile/run `.aaps` workflows with `aginti aaps ...`, and AAPS can call AgInTiFlow as the backend implementation agent with `aaps prompt "goal" --backend aginti`. See [docs/aaps.md](docs/aaps.md) and the package [https://www.npmjs.com/package/@lazyingart/aaps](https://www.npmjs.com/package/@lazyingart/aaps).
 
 ## Local API Quick Reference
 

package/docs/aaps.md

@@ -9,6 +9,11 @@ The integration is intentionally lightweight. AgInTiFlow does not vendor the AAP
 3. `aaps` on `PATH`.
 4. A sibling development checkout at `~/ProjectsLFS/AAPS/scripts/aaps.js` when present.
 
+There are two useful bridge directions:
+
+- `aginti aaps ...`: AgInTiFlow is the interactive runtime and calls the AAPS CLI to inspect, validate, compile, dry-run, or run project workflows.
+- `aaps prompt "goal" --backend aginti`: AAPS writes a durable backend-agent handoff under `.aaps-work/prompts/` and invokes AgInTiFlow as the implementation agent for the goal.
+
 ## CLI
 
 ```bash
@@ -46,6 +51,16 @@ Current lightweight adapter boundary: prompt-only AAPS tasks are recorded as han
 
 `aginti aaps install` installs `@lazyingart/aaps` as a project dev dependency only when the current project has `package.json`. Use `aginti aaps install global` only when you intentionally want a global npm install.
 
+If you want AAPS itself to hand a top-level goal to AgInTiFlow, use the AAPS CLI:
+
+```bash
+aaps prompt "Create and validate an executable workflow that writes reports/smoke.md" --project . --backend aginti
+aaps "Create a small AAPS workflow and run it" --project . --backend aginti
+aaps prompt "Prepare the backend prompt only" --project . --backend print --json
+```
+
+The generated AAPS handoff is sandbox-aware: it asks the backend to prefer installed `aaps`, use Docker-safe `npx -y @lazyingart/aaps@<version>` when package installs/network are approved, and use a source checkout only when that path is visible inside the active sandbox.
+
 ## Project Shape
 
 `aginti aaps init` creates a starter project without overwriting existing files:

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@lazyingart/agintiflow",
-  "version": "0.20.83",
+  "version": "0.20.84",
   "type": "module",
   "description": "Low-cost, project-aware Web and CLI agents with DeepSeek/Venice/OpenAI routing, visible tool calls, durable sessions, scouts, AAPS, SCS, and guarded local execution.",
   "license": "Apache-2.0",