add AI agent context

[LexLuthr]

Supersedes #1105

[Reiers]

Review: AI Agent Context

Nice work, Lex. The modular context loading with selective bundles is the right approach for keeping AI chats focused without drowning them in tokens. The separation between runtime context and maintenance prompts is clean, and the decision/uncertainty tracking in 07 and 08 is exactly what prevents repeated mistakes across sessions.

I went through every context file and cross-checked claims against the actual codebase. Here is what I found:

Technical accuracy issue in 01-architecture.md

The pipeline flow description says:

SDR -> TreeD/TreeRC/Synthetic -> PreCommit submit -> PoRep -> Finalize -> MoveStorage -> Commit submit

The actual pipeline has separate DB stages: task_id_tree_d, task_id_tree_c, task_id_tree_r, and task_id_synth. While task_treerc.go handles both TreeC and TreeR in one file, they are distinct pipeline stages in the schema. Suggest:

SDR -> TreeD -> TreeC/TreeR -> Synthetic -> PreCommit msg -> PoRep -> Finalize -> MoveStorage -> Commit msg

Also, the schema uses task_id_precommit_msg and task_id_commit_msg (not "submit"), which matters for consistency with the DB column names the AI will actually encounter.

Missing context file 02

Numbering goes 00, 01, 03, 04... No 02 exists. If this is intentionally reserved (maybe for task engine internals or the HarmonyTask lifecycle?), add a comment in index.md so future contributors do not wonder if it got lost.

AGENTS.md finalize section

The FFI_USE_OPENCL=1 env var in the verification step is correct but unexplained. An AI running make gen for the first time will hit build errors on machines without CUDA. One line would help:

1. `LANG=en-US FFI_USE_OPENCL=1 make gen`  # OpenCL flag avoids CUDA build dependency during codegen

09-chat-bootstrap.md cold start gap

If someone opens a fresh AI session and only loads 09-chat-bootstrap.md, they get instructions to load other files but zero project context. Adding a 2 sentence summary directly in the bootstrap (e.g., "Curio is a clustered Filecoin Storage Provider runtime replacing lotus-miner, backed by YugabyteDB for distributed coordination") would make it self-sufficient for quick questions.

set-target-state help text still references none

In the description block for setTargetUnsealStateCmd, the help text was updated to say (true, false) but the body still explains none behavior:

If the target state is none, curio will not change the current state of the sector.

And the case "none" branch still exists in the switch. If none is being deprecated from the help, the description and switch branch should be cleaned up too, or the help should keep mentioning it.

Minor suggestions

• .gitattributes: Consider adding scripts/ai-context/**/*.md linguist-documentation so these docs do not inflate code change stats in GitHub PR diffs.
• 99-context-validation-loop.md (145 lines): Very thorough, but for practical adoption consider marking the full validation as "run periodically" rather than every context update. The core checks in check-context.sh already cover structural correctness.
• Snap pipeline in 01-architecture.md says "UpdateEncode -> UpdateProve -> UpdateSubmit" but the schema uses task_id_encode, task_id_prove, task_id_submit (no "Update" prefix). Small thing, but AI agents will search for the exact names.

What is solid

• The DB semantics doc (03) is excellent. The coordination pattern descriptions match the actual codebase precisely.
• The common patterns doc (05) correctly identifies the compare-and-set ownership model and the enqueue/send/watch/finalize chain.
• The open questions (08) correctly flags PDP table primacy uncertainty, which I can confirm from direct experience with the codebase.
• The coding preferences (04) are pragmatic and well-calibrated.
• The check-context.sh script is a nice touch for CI hygiene.

Overall this is a well-structured addition. The few accuracy fixes above are straightforward.

Capri Curio Counsel

[Reiers]

Suggested change

	- Canonical PoRep flow: SDR -> TreeD/TreeRC/Synthetic -> PreCommit submit -> PoRep -> Finalize -> MoveStorage -> Commit submit.
	- Canonical PoRep flow: SDR -> TreeD -> TreeC/TreeR -> Synthetic -> PreCommit msg -> PoRep -> Finalize -> MoveStorage -> Commit msg.

Schema has separate task_id_tree_d, task_id_tree_c, task_id_tree_r (not combined "TreeRC"), and uses task_id_precommit_msg / task_id_commit_msg (not "submit").

[Reiers]

Suggested change

	1. `LANG=en-US FFI_USE_OPENCL=1 make gen`
	1. `LANG=en-US FFI_USE_OPENCL=1 make gen` # OpenCL flag avoids CUDA build dependency during codegen

[Reiers]

Add a cold start summary so this file works standalone:

Suggested change

	## Purpose
	## Purpose
	- Define a lightweight, repeatable way to start new AI chats without overloading context.
	- Curio is a clustered Filecoin Storage Provider runtime replacing lotus-miner, coordinated through YugabyteDB. Single binary, multi-node, multi-miner.

[Reiers]

Correction on my earlier suggestion: I checked the code and the registered task names are indeed UpdateEncode, UpdateProve, UpdateBatch (+ UpdateStore for move storage). The DB columns differ (task_id_encode, task_id_prove, task_id_submit), but the task names in harmony_task rows, logs, and UI match your original wording. Ignore my previous suggestion on this line. The original is fine, though you could note that the submit task is actually named UpdateBatch not UpdateSubmit:

Suggested change

	- Snap flow is separate but integrated: UpdateEncode -> UpdateProve -> UpdateSubmit (+ storage/finalization tasks).
	- Snap flow is separate but integrated: UpdateEncode -> UpdateProve -> UpdateBatch/Submit (+ UpdateStore for move storage).