agentic-art-orchestration

Imported from masa-san-jp/agentic-art-orchestration (AGENTS.md). Install upstream with npx skills add masa-san-jp/agentic-art-orchestration. Copyright stays with the author.

Repository instructions

Automatic plan projection uses the qualified Production CLI and opaque attestation, not parent-owned headings or semantic schemas. The automatic plan lane uses native mechanical attestation and does not wait for human review; missing review blocks only a separately requested manual/work publication. Never invent public consent. See docs/issue-193-execution.md for v2 provenance, revision and rollback checks. Target Git operations and real migration stay gated.

AAK：自律制作と累積知識の追加系列

今回の追加要件は仕様SSOTのprinciples/authority/compatibility、実装順・検証・再開は実装計画SSOTを読む。Issue参照版は b0e7c7f8d0a1f756fa708deef4fb380a62e45e0d。既存機能全体の仕様を置き換えない。

芸術の契機を「精霊や風が運び、人間が受け取って具象化する」と捉えるプロジェクトの精神を維持する。外部エージェントが既存の半決定論的ハーネスを動かす。LLM/daemonの内蔵を必須にしない。

次taskはqueueとstate、.venv/bin/python tools/project_status.py --format jsonから確認する。AAK-01 → AAK-03 → AAK-04以降は計画DAGの依存を満たす最小ID、AAK-02は最後。既存Issueの前提はownerのcandidate commit・contract version・受入証拠を確認し、CLOSEDだけで通過させない。

機械契約 config/aak-task-projection.json とqueue参照は2つのMarkdownからの実行用投影であり、第三の仕様ではない。初回は .venv/bin/python tools/issue_intake.py --register-aak で冪等登録する。validatorは投影・参照hash・owner・DAGを照合する。子のschema/本文を親へ複製しない。merge/release/公開/実n=1移設のhuman gateを維持する。

Mission

エージェントが自律的に制作プランを出力するところまで動くエージェントハーネス。作品を作る仕組みそのもの。

これが目的である（2026-08-25 マサさんの言葉のまま）。版番号は目的ではない。以下の control plane、境界契約、品質ゲート、qualification は、すべてこの目的のための手段である。

要件は README の「要件」節を正とする。読まずに着手しない。

Read order

1. docs/20260811-agentic-art-orchestration-system-design-specification.md
2. docs/20260811-agentic-art-orchestration-repository-execution-plan.md
3. PLANS.md
4. execution/task-queue.yaml
5. execution/state.yaml と execution/handoff.md
6. 変更対象に最も近いschema、文書、テスト

Task selection

• 依存がすべてDONEである最小IDのREADYタスクを1件選ぶ。
• READYがなく、依存完了済みBACKLOGがある場合は、最小IDをREADYにする。
• READYも依存完了済みBACKLOGもない場合は、.venv/bin/python tools/issue_intake.pyで未登録のopen Issueをread-only観測し、SSOT最低要件を満たすIssueだけを依存関係付きでtask-queue.yamlへBACKLOG/READY登録するcommitを1つ作る。登録だけを行い、実装は次のtaskで行う。

Issue SSOTの最低要件は、(1)観測可能な受入条件、(2)対象repository、(3)検証コマンド、(4)human gateの有無、の4点である。欠落Issueはqueueへ登録せず、intake reportでUNQUEUED_NEEDS_SSOTと不足項目を残す。Issueコメントによる要求はtaskで明示された場合だけ行い、Issue本文全文は親へコピーしない。

• 原則1タスク1commit。子repo変更が必要なら親と子を別commit・別PRにする。
• 完了判定はファイルの存在ではなく、acceptanceとchecksの観察可能な結果で行う。
• セッション記憶を前提にせず、repo内のstateとhandoffだけで再開可能にする。

Production planning mode

このrepoを利用するエージェントとして起動された場合、ユーザーにテーマ・repo名・slug・titleを質問しない。まず.venv/bin/python tools/credential_free.py --state-root <external-state-root> -- .venv/bin/python tools/self_hearing.py openを実行し、offeredならpacketのintent全行、why、anchors、questionを一問だけ会話で示す。回答は子repoのannotated block形式で.venv/bin/python tools/credential_free.py --state-root <external-state-root> -- .venv/bin/python tools/self_hearing.py answerへ標準入力し、断り・無応答はskipにする。packetや回答は親のstate・log・Issue・PR・handoffへ保存しない。どのoutcomeでも同じrunのtools/run.pyを実行し、ヒアリング結果で停止しない。その後READMEとdocs/agent-runtime-guide.mdのテーマ未指定入口を実行し、pin済みsignalからgate通過候補を選び、候補由来のcreative_questionをテーマ案としてResearchへ渡す。明示intentは任意の順位付け入力であり、必須ではない。起動時にworkspaceがmissingまたはcleanなpin driftだけなら、既存checkoutを変更せずGit外の専用qualified workspaceを作ってResearch/Productionへ継続する。startupがBLOCKEDの場合はテーマやPLAN_READYを捏造せず、観測された解除条件と保存済みresume commandを処理する。AT_EDGE、RESEARCH_PENDING、AT_PRODUCTIONは未完了であり、手動制作案へ置換して完走扱いにしない。制作session、ヒアリングの全操作、runと保存済みresume commandは.venv/bin/python tools/credential_free.py --state-root <external-state-root> -- <command...>で起動する。PUBLIC 子repoにはtoken発行・loginは不要であり、入口が空のGH_CONFIG_DIR（700）、Git設定、HOMEとSSH認証の隔離を行う。必要なprofile・workspace・agent設定は絶対pathで明示する。Project-owned v2の初回起動は入口用の外部一時rootを別に使い、Project配下はresolver検証後に作る。子をprivateへ戻した場合だけ、operator runbook §2の専用GH_CONFIG_DIR/read-only tokenを使う。PR作成・mergeは別sessionで行う。

Work protocol

inspect → claim → lock → edit → test → child-gates → diff → record → release

1. 親の仕様、task、対象子repoのAGENTS/Issue SSOT/testsを読む。
2. stateにtask、対象repo、開始点、想定変更を記録する。
3. 同じrepo/pathを扱うactive leaseがないことを確認する。
4. 最小差分で実装する。
5. 親checkと変更した各子repoの品質ゲートを実行する。
6. repoごとのGit状態と差分を個別確認する。
7. task、判断、発見、commit、テスト、次の開始点を更新する。
8. state.yaml、handoff.md、task-queue.yamlを含む実行SSOTのcommitを、lease解放前に作業branchからoriginへ通常のfast-forward pushで公開する。force pushと既定branchへの直接pushは禁止し、pushまたはremote確認ができない場合はUNKNOWN／未pushを記録してleaseを解放せず停止する。
9. leaseを解放する。

Ownership and authority

• repositories.yamlは統合対象と取得方針の正本。
• 既存4repoはcore setとして保持し、追加repoはmanifest validation、knowledge profile、snapshot、個別quality gateを通してappendする。既存entryとの置換で追加しない。
• 子repoの要件・schema・データは常に子repoが正本。
• normalized research signalは境界形式だけを規定し、子の内部schemaを上書きしない。
• task-queue.yamlは親repo実装順の正本。
• state.yamlは現在の再開点、handoff.mdは人間可読の引継ぎ。
• data/とrepos/は生成物。手編集しない。
• Google Drive上の成果物は外部artifactの正本。親はopaque ID、hash、provenance、access scopeだけを保持する。
• 明示・推定feedbackの実行順はtask-queue.yaml、domain内容の採否は対象子repoのIssue/PRが正本。
• AAK知識交換は config/knowledge-owners.yaml と tools/knowledge_cycle.py の共通境界を使う。domain payloadの妥当性はowner validatorが決め、親はenvelope・receipt・分散再開だけを検証する。

Safety invariants

• 子repoを親履歴へvendor copyしない。
• PRIVATE_RAW、RESTRICTED、個人識別情報、認証情報を親へ集約しない。
• dirtyな子repo、detached HEAD、未push commit、branch不一致を黙って変更しない。
• hard reset、強制push、branch削除、Issue/PR削除を自動実行しない。
• すべての入力にrepo IDとsource commitを付ける。
• marketingの鮮度切れ、self-modelの同意範囲外、art-historyの根拠不足を正常値へ変換しない。
• 失敗した品質ゲートをskip・削除して通したことにしない。
• branch作成・commit・draft PRまではtaskで明示された場合に限る。merge、release、削除は人間承認を要する。
• 利用エージェントはユーザー体験を優先し、改善・監査処理を同期実行して応答を不必要に待たせない。
• Drive artifactはcreate-onlyとし、修正は新artifact + derived_from/supersedesで表す。既存artifactを上書き・削除しない。
• 会話全文をGitへ保存しない。暗黙の不満・欲求は根拠とconfidenceを持つ仮説として扱い、ユーザー事実へ昇格させない。

Stop conditions

次だけはBLOCKEDにして停止する。質問だけを残さず、観測事実、選択肢、推奨、影響、解除条件を記録する。

• 子repoのIssue SSOT同士が両立せず、adapterで解決できない。
• 機微情報の外部送信、同意拡張、公開範囲変更が必要。
• 破壊的Git操作、既定branchへのmerge、releaseが必要。
• データ損失または不可逆なschema migrationの可能性がある。
• 認証・権限がなく、read-onlyの代替でも受入条件を満たせない。
• acceptanceが相互矛盾し、保守的既定値でも解消できない。
• Driveへの外部送信に必要な同意・保存先・権限が確定していない。
• 推定feedbackだけを根拠に同意範囲、公開範囲、ユーザー属性を変更する必要がある。

Required checks

Fresh cloneでは、まずREADME.mdの正準bootstrapを上から実行する。READMEにはrepo内.venvの作成と依存関係準備を含める。full suiteまで行う場合は、同じ節のoffline fixture生成を先に完了する。PUBLIC 子repoの読取はGitHub認証なしでtools/credential_free.pyを使う。ネットワークなしの検証はREADME記載の--offline-fixture経路を使い、システムPythonへ依存関係をインストールしない。

.venv/bin/python tools/validate.py --check
.venv/bin/python -m unittest discover -s tests -v

workspace実装後は workspace status、audit、変更子repoのmanifest記載commandも実行する。 interaction実装後はnetworkless fake Drive、append-only artifact、feedback routing、interaction E2Eも実行する。

Completion report

• Task ID
• 対象repo
• 観察可能な変更
• acceptance達成数
• 親検証と子品質ゲート
• repoごとのcommit SHA
• 機微情報確認
• 外部artifactのcreate-only確認とopaque参照
• explicit/inferred feedbackの区別
• 未解決
• 次taskと最初の1操作

Instance identity boundary

• instance-profile/v1 のinstance/creator/modeと全8 owner mappingを検証し、個人identityをremote名、clone元、cwdから推測しない。
• code checkoutとknowledge storeを別refとして扱い、dirty/divergedな既存worktreeをresetしない。
• forkのupstream write、remote push、公開projectionは明示設定と既存human gateなしに行わない。
• public-seed-only を個人固有性の合格証拠にしない。

Requested delivery completion (Issue 217)

In a session launched through tools/credential_free.py, for a request to output to Project, run .venv/bin/python tools/credential_free.py --state-root <external-state-root> -- .venv/bin/python tools/run.py --cycle-context <external-context.json> --project-root <project-checkout> --state-root <project-checkout>/.agentic-art/state --delivery-target project-local. The context/profile must explicitly authorize public-catalog projection and select the Project root; an internal profile mismatch is an error, never silent SKIPPED success. The saved context records project_root, delivery_contract: {contract_version: delivery-contract/v1, target: project-local}, the repo-local destination-resolution/v2 in run state, and the exact resume command. Legacy contexts keep their existing internal/committed-catalog semantics; no profile is silently migrated.

Continue the returned agent actions through Production plan generation, native automatic attestation, canonical projection, native Project lineage initialization and local receiver validation. The normal automatic plan lane does not call the manual review API or wait for approval. Reuse existing native approvals only for a separately requested manual/work publication; missing approvals return the prepared target and precise remaining review decisions for that lane. Run the native runtime bootstrap when a freshly built plan has not yet initialized its event log. Do not fabricate approvals. A human wait preserves successful work and does not consume the no-progress retry budget.

PLAN_READY and batch PASSED describe stages, not final delivery. For the cycle entry, only delivery_completion.status=COMPLETED with the requested target is the overall completion report. Required knowledge saves, receiver hashes and creator/origin must verify. A local receipt does not prove Git commit or remote synchronization. GitHub Actions, account billing and a built-in provider are not required. Existing AAK internal evidence is not public-catalog acceptance.

Clone/fork users may select the Project-owned repo-local contract with --project-root <absolute agentic-art-project checkout> or AGENTIC_ART_PROJECT_ROOT. The shared v2 resolver derives all private roots below .agentic-art/, runs the pinned Project validator and Git boundary checks before creating anything, and rejects v1 profile/root mixing as AMBIGUOUS_DESTINATION_MODE. It never infers a remote, visibility, commit, or publication permission.