Workflow Manifests

Purpose: Describe the machine-readable workflow sidecars that accompany the runnable Octant v2 setup paths. Audience: Developers and coding assistants that need exact commands, stop conditions, or expected git-status snapshots during setup. Level: Reference Source of truth: The linked workflow pages remain authoritative for narrative guidance; the JSON manifests mirror those pages in a machine-readable format. Use this page when: you want repo pins, exact commands, required environment variables, success criteria, or first-error routing without reconstructing them from prose. Do not use this page for: replacing the workflow pages themselves — read the underlying tutorial or quickstart for the full explanation.

The JSON files listed here are shipped with this docs bundle so assistants can consume the setup surface directly. They are intentionally narrow: each one covers a single runnable workflow and encodes the commands, expected outputs, stop conditions, and git-status snapshots that matter during the cold-start phase.

Included sidecars

Workflow	Human page	Bundle file
Local Development Quickstart — Path A (octant-v2-core)	Local Development Quickstart	09_agent_assisted_development/workflow_manifests/local-development-core.json
Local Development Quickstart — Path B (octant-v2-strategy-foundry-mix)	Local Development Quickstart	09_agent_assisted_development/workflow_manifests/local-development-starter.json
Hello World Strategy	Hello World Strategy	09_agent_assisted_development/workflow_manifests/hello-world-strategy.json

Starter-template helper

The starter-template path also ships a small helper script:

• 09_agent_assisted_development/scripts/reconcile-starter-pin.sh

Use it after any later git submodule update --init --recursive if you want a repeatable way to:

• re-pin dependencies/octant-v2-core to 36ed6ad6665661a18f83394d561fa75c68ccf4ac, and
• rewrite the optional local foundry.lock submodule entry so its recorded revision matches the same docs pin.

This helper does not make the working tree clean again. For the audited starter snapshot, a modified submodule and local lockfile state are still expected after the docs pin is applied.

Error classes used in the manifests

Class	Meaning	Typical examples
tooling	A local tool or dependency bootstrap step failed before the code itself could be evaluated	corepack enable permission error, forge soldeer install panic, missing imports after a failed install
network	Git, registry, or DNS access failed	Could not resolve host, ENOTFOUND registry.yarnpkg.com
RPC	The fork-test endpoint is missing, invalid, or not archive-capable	fork creation fails, historical state unavailable
docs drift	The repo pins and the docs no longer line up, but the setup layer is healthy	signature mismatch, starter-template compatibility note not applied
code issue	The environment is healthy and the code itself is now the likely problem	compiler or test failure after dependencies, pins, and compatibility fixes are all correct

How to use these files with a coding assistant

1. Load llms.txt.
2. Load the human workflow page you are following.
3. Load the matching JSON manifest from this bundle.
4. If the first error matches one of the manifest's stop_conditions, stop and fix that class of problem before asking the assistant to rewrite code.

This keeps the docs human-readable first while still giving agents a clean place to read exact setup state.