orchestrate制御

2026-10-28 07:25 JST Ryzen AI NPU/GPUモデル台帳・リース既存実装の実機照合（非破壊）。

【既存管理】

• Ryzen C:\Users\ito\infra\local-llm-lifecycle\controller.py (稼働PID 19144) はレーン別RLock、active request counter、idle reaperを保有。NPU TTL=900秒、管理対象Vulkan35B TTL=120秒。ただし永続owner付きで全GPUプロセスを覆うリースではない。
• Agent Control Tower agent_tower/locks.py ResourceLockManager はSQLite TTL leaseを実装。現時点でryzen-ai GPU/NPUリソースのactive leaseは観測されず。Gateway lock.list 0件。B550独自のオンデマンドGPU leaseは別系統。
• Ryzen VulkanのOrnith 9Bは既存lifecycle管理のOrnith 35Bレーンとは別の直接起動プロセス。全GPU経路の統一排他は未確認（自動モデル切替へ解放してはならない）。

【実測モデル】

• NPU: FLM gemma4-it:e4b :8100 PID15644 稼働 (実測ctx32768,prefill4096)。管理設定はctx16384,prefill8192で不一致。Gemma4 12Bは別のNPU laneに設定・待機。FLM catalog上のGPT-OSS20B、LFM2.5等はランタイム配置まで未確認。
• GPU: llama.cpp Ornith 9B :8200 PID7084 稼働。GGUFファイル12件確認（35B複数版、Qwen3 Coder30B、KAT Coder、Gemma4等）。ファイル存在と実稼働は明確に区別。
• Gateway runtime/local-llm/registry.jsonのactiveはOrnith35B/8111だが実測は9B/8200。既存の意図された設定は勝手に上書きせず、観測台帳上にconfig driftで記録。

【整備・検証】
MN55既存Fleet Observer(5分周期)へread-only照合を追加。
実装: /home/ito/services/fleet-observer/ryzen_models.py
台帳: /home/ito/services/fleet-observer/reports/ryzen-model-ledger.latest.json
通常サマリー: /home/ito/services/fleet-observer/reports/latest.json -> ryzen_model_ledger
モデル一覧54レコード(FLMカタログ、GPU GGUF12件、Lifecycleレーン。カタログ掲載と導入済みは未同一視)。不一致5項目を自動検出。
専用5件＋Fleet Observer既存9件=14テスト全PASS。実タイマー2026-10-28 07:25の実行成功、reportにOBSERVEDが記録された。既存collectorは事前にバックアップ済み。
本番モデル停止/切替なし、NPU/GPU設定変更なし。

【次の受入課題】
既存WorkOSのenvironment leaseまたは同等の一元的owner/TTLを使い、直接起動9B、lifecycle 35B、NPU各モデルの全ての起動経路に同じ資源単位の排他ゲートを適用する。コンフリクト時はfail-closed、プロセス実体とPID、Lease owner/run_id、TTL、renew/expire/recoveryを照合。Gateway設定の選択名と実測名を表示レイヤーで分離し、意図された35B構成は保全する。

2026-10-28 08:05 JST: Ryzen AI NPU/GPUリース既存Work OSへの適用（安全段階）を完了。

【稼働・証跡】

• VPS Agent Control Tower production SQLiteにenvironment:ryzen-ai:npu と environment:ryzen-ai:gpu の2つのactive ResourceLockManager leaseを確認。ownerはPID/起動時刻/モデル由来、TTL=180秒。
• MN55 model-lease-occupancy.timerを1分毎に常設。2026-10-28 08:05のFleet Observerレポートは両lane LEASED、NPU Gemma4 E4B PID15644、GPU Ornith9B PID7084。タイマー正常更新。
• VPS /root/projects/ryzen-model-leases/lease_service.py: WorkOS既存LeaseManagerファサード。Git df89341。4テスト合格、別ownerでの競合取得はGPU/NPU両方拒否。
• MN55 /home/ito/services/fleet-observer/model_lease_occupancy.py + ryzen_models.py + collector.py: 実PIDとleaseの照合/更新。モデル台帳/リース実測結果をlatest.jsonへ統合。21テスト合格。設計と切戻し: docs/ryzen-model-leases.md。
• Windows Lifecycle controller.pyをバックアップ後修正。冷間起動時の同一アクセラレータ二重起動拒否、設定不一致時の自動モデル停止/切替拒否、stale-ready判定改善。管理プロセスのみPID19144→212180へ切替、NPU/GPU推論PID維持。独立import試験でNPU12B/GPU35Bの競合起動が両方BLOCKED。
• Scheduled Task OrnithToolRouterの起動アクションをguarded-task-start.ps1へ変更、稼働GPU PID維持、XMLバックアップ済。FLM-NPU-Server wrapperも競合拒否。FLM_GPT_OSSもguarded launcherに変更（Disabled維持）。
• Gatewayのlegacy GPU runtime_start/stop/switch/tuneは従来無条件にWindows llama-serverを停止するコードのため、fail closedへ変更。Source commit 3bd0a0f/a101549、blue/greenへ配置しplugin hot reload。読み取りステータスはRUNNINGでmutation_guardを表示。実際のswitch/stop呼び出しはWORKOS_LEASED_EXECUTOR_REQUIREDを返す。Gateway周辺テスト22件合格。モデル稼働継続。
• 実験で使わない専用SSH公開鍵・MN55の未起動Broker案は削除し、新たなネットワーク受付/追加認証鍵を残していない。

【未解決】
この段階は既存モデルの事後lease同期+既知Launcherの多重起動防止。起動前の原子的WorkOS lease取得→新PID所有者引継ぎ→releaseまでの統合実行は未実装で、任意の手動rawコマンド起動は防げない。旧Gateway直接モデル切替は安全上いったん利用不可。残作業を #11676 に分離。#11675はこの点でまだ完了ではない。

2026-10-28 B550電源復旧後の運用確認。B550 boot 07:55:11 JST、Tailscale 100.64.0.4 online/ping 27-28ms、SSH/MCP connected。RX6800XT×2認識、b550-llm-queue.service・reaper.timer稼働。B550のGemma4 12B(gemma4jp)で実キュー推論 queue_id=3e5c2c793d30、出力「B550推論確認OK」、status=done。モデルPID65107・GPU1の1枚割当、リース正常取得。期限後にreaperでモデルPID終了、lease.status=off、servers=[]への復帰を実測。Penpot HTTP 200/healthy。Strataや大型モデルの実推論は未検証。B550 / 468GB中391GB使用、空き53GB(89%)。q35_9は登録されるが現在active_names()許可リストから外れ、キューはinvalid modelで拒否。Ryzen側はNPU Gemma4 E4B PID15644、GPU Ornith9B PID7084、MN55 1分周期の既存WorkOSリースが08:18時点でも両方LEASEDで正常更新。その他: Ryzen AI側のI-O DATA SSPH-UA約1TB(Disk2)がイベントID154を直近15分176件記録し、Get-Diskでは列挙されないため別件でハードウェア確認が必要。対象ディスクへの変更は一切実施していない。

【AI Swarm Commander / MN55司令塔 ハーネス整備計画案（2026-10-28、計画のみ・未適用）】
親タスク #11675、Ryzenの原子的モデル起動/リース統合 #11676。

■ ゴール
MN55（OpenDots/UI・Scheduler/Task DAG・Worker Dispatch・Supervisor・Context Packs・Hindsight・監視）を単一のスワーム司令塔とし、B550（2GPUの重推論/コード生成/画像）とRyzen AI（NPU/GPUの軽量判断/レビュー/Windows・ブラウザ操作）を、タスクに従い協調させる。VPS既存Agent Work OS/Control TowerはSSOT（永続タスク/監査/承認/ResourceLockManager/Redmine）、MCP Gatewayは権限付きツールファサード。MN55とVPSで同一タスクを二重配車しない（swarm名前空間のLeaderはMN55、VPS現行Supervisorは同名前空間を配車禁止）。Work modeは使わない。

■ 現況確認済
MN55 62GiB RAM、NVMe空き139GiB、4TB HDD ext4 /mnt/hdd4tb 空き3.4TB。OpenDots、model-router (127.0.0.1:39212; B550/Ryzen upstream両方healthy)、Hindsight、PentAGI、Fleet Observer、MN55 local-llm-harness(12テスト合格)稼働。B550は電源復帰/2GPU認識/キューとリースE2E成功、ただしシステムディスク89%。RyzenのNPU/GPUリース1分更新。VPS Work OSにはtask_graph/orchestrator/sdk/locks/evidence/budgets/supervisorが既存。Orchestrate WaveはworkspaceIsolationとartifactChecksumReadbackあり、artifactContentVerification=false。WorkOS completion policyは現在independent_verifier_required=false / completion_claim_is_sufficient=trueで、設計原則の厳格DONEと不一致。Device Registry上B550=offlineのまま、実機online。Gateway GPUモデル選択は登録35B/実観測9Bと不一致。Ryzenモデル切替は安全のため旧Gateway経路がfail closed。
OpenDotsモデルルータには短文ロールのauto-plan/auto-build/auto-verifier等。Strataの長時間タスクは対話タイムアウトから分離してDurable Task経由に限定。

■ 最小共通コンポーネント（既存再利用）

1. Shared TaskContract & Graph validator（task_ref/run_id, immutable plan revision, depend_on, requirements, read/write scope, budget, expected evidence）
2. MN55 swarm scheduler/dispatcher（既存WorkOS TaskGraph/Worker SDK/ResourceLockManagerをHTTP/MCP薄いアダプタで使用。SQLiteを二重正本にしない。MN55にはretry/outboxのみ）
3. Provider & Tool Worker Adapter（model-router 39212、B550 queue/lease、Ryzen NPU/GPU lease、MCPGateway/Windows-MCP。モデル出力はJSON schema検証し、許可された決定論的ツールだけ実行）
4. Workspace Executor（Git worktree per node/run, base SHA固定, allowlist path, rootless or locked-down Docker sandbox, no network default, conflict detection）
5. Evidence/Verification Gate（test/lint/diff/security/requirements/artifact SHA readback、独立Verifier、DONE CASと監査イベント。モデルの『完了』自己申告は証跡にならない）
6. Recovery & Observable UI Adapter（OpenDots実行履歴、ストリーミング進捗、保留/再試行/復旧、Hindsightに承認済み要約のみ）

■ 役割の物理マッピング（論理役割と実GPUスロットは分ける）
MN55: deterministic planner-validation, scheduler, verifier controller, sandbox tests, memory, monitoring, integration queue。
B550: Qwen3.8 27B/Strataなど重推論のPlanner/Builder/難問担当、Gemma4 12Bの軽量開発、Qwen-MMの認識。B550大モデル2GPU使用時は別GPU作業を同時起動しない。
Ryzen: NPU E4Bのtool/router/triage、Vulkan Ornith9Bの軽量レビュー/修正支援、Windows/browser実操作。NPU/GPUごとに権限分離。
独立Verifier: 実テスト・読み取り照合は決定論的、別LLMレビューは補助。PentAGIは許可されたセキュリティスコープのみ。

■ スケジュール（1名換算の見積: MVP数営業日、運用全体約4-6週）
P0（2-3人日）現状差分修正：実測device_registry更新、Gatewayモデル実測/設定分離、GPUリースの原子的開始 #11676を別ゲート、WorkOSでswarmタスクのindependent verifier/strict DONE強制、Artifact内容照合、既存非対象の監視誤報を整理。
P1（3-4人日）MN55 commander.service追加。WorkOS Task/Runプロトコル再利用、1 task→DAG plan→単一worker実行→evidence→DONE、再実行時冪等性。OpenDotsからの受付と追跡。
P2（4-6人日）B550/Ryzen worker adapterとモデル役割ルータを統合。モデルリース・GPU/コンテキスト容量・budget・TTL・fallback・JSON schema validation、冷間起動/モデル不達/タイムアウトを検証。
P3（4-6人日）並列DAGとper-worker Git worktree。ファイル/Repo排他、競合検出、レビュー/統合直列化。3役（Planner・Builder・Verifier）E2E。B550ディスク残53GBなので大容量の作業キャッシュはMN55 HDDに置く。
P4（4-5人日）独立QA、脆弱性/秘密漏洩検査、障害回復・モデルフェイルオーバー、電源断/ネット断/lease expiry/重複メッセージ試験。
P5（4-6人日）開発/セキュリティ/移設の定型RunbookとOpenDots進捗UI。変更はworktreeだけ→ staging QA → 専用承認で実プロジェクト統合。破壊的移設/本番デプロイは別承認。
計21〜30人日目安、依存やUI要件で変動。

■ 初回MVPデモ
「小型Pythonライブラリの不具合を修正する」→MN55でDAG（調査→修正→テスト→レビュー→統合保留）を作成、B550でコード提案、Ryzenまたは別LLMでレビュー、MN55 Dockerでテストし、diff/test SHAをWorkOSへ記録。作業ワークスペースと本番リポジトリは隔離。外部デプロイなし。

■ 完了受入基準

• Task/Run/Tool/Worker/ArtifactにIDあり、時系列と基準Git SHAに紐づく証跡100%。
• 1task-multi-runでリトライ時はrun_id変更、同じファイル/同じGPUの二重取得0、全リースは所有者・TTL付。
• 低リスクfixture 12種で依存順・並列・故障復帰を全PASS、独立検証なしDONE=0、未承認本番変更=0。
• B550 OFF/ON、Ryzen NPU/GPU不達、MN55/VPS/Tailscale断・lease TTL切れを試験。証跡なしSUCCESSを禁止し、HOLD/FAILEDへ正しく遷移。
• 全モデル切替は原子的事前lease/プロセス引継ぎが実装・試験されるまで従来通り禁止。旧legacy GPU kill路線再開なし。
• HDDバックアップ/リストア実査、Secret Brokerの権限境界、Redmine追跡・OpenDots進捗UI。
• 観測/試験/成果物の真偽は常に機械的evidenceで判定。自動化に昇格するのは受入後。

■ 運用リスク
Ryzen AI外付けI-O DATA 1TBにはEvent154 I/O hardware error頻発（#11677）。重要なWorkOS/Artifact SSOT/バックアップの保存先に使わない。MN55 HDD /mnt/hdd4tbはバックアップとキャッシュ、稼働DBはNVMe。VPSへ証跡とバックアップ同期。B550 root使用率89%、大型のworktree/モデルを増殖させない。Chatworkバックログ（OpenDots README）を勝手に再生しない。

2026-10-28 11:47 JST — P2 Git Worktree + parallel DAG AI swarm implementation executed on MN55, B550, Ryzen AI and Work OS.

【Results】

• MN55 created isolated parallel-worktrees per job, 2 independent Git detached worktrees from immutable base SHA, strict file allowlists, independent worker audit, path/parent/ancestry comparison, overlapping changed-path fail-closed, deterministic cherry-pick only after both builds finish.
• B550 Gemma4 12B built math_ops.py/test_math_ops.py; Ryzen Ornith 9B built text_ops.py/test_text_ops.py. Both model processes ran concurrently (monotonic intervals overlapped, not merely parallel task declarations).
• Both isolated generated-test suites passed 2 tests each in read-only/no-network Docker.
• MN55 integration after both Work OS tasks were evidence-verified: 4 files integrated without conflicts, independent acceptance suite 8/8 tests passed, SHA-256 byte identity between worker artifacts and merged source verified. No production repository, deploy, or live model switch changed.
• VPS Work OS TaskGraph 3/3 completed, 6/6 mandatory evidence criteria verified, 12 artifacts registered, 3 distinct work_runs, path resource leases all released for each completed job.
• Real E2E #1: pswarm-3eaa3470e6414dd8be5a (base 424a01cea4ae32efa586db738a1f0cd01d16ede9, merged c3128892506622184b7707fd7e4db3394b7cb0e9), verified.
• Real E2E #2 (systemd service queue): pswarm-d0a5473977144a5087d1 (base e3afae492f07be2db017312b377649fc74177a1e, merged 9c1375c12b25f60d71b791f0e7f09b6da689b737), verified. A start-before-run HOLD occurred due NixOS systemd SSH global config permission error with NoNewPrivileges. Verified fix by ssh -F /dev/null + pinned private key and StrictHostKeyChecking=yes. After confirming both Work OS nodes remained ready and worktrees untouched, the same job was safely requeued. Recovery history retained in state, final VERIFIED. Duplicate completed-job replay verified idempotent with local Git HEAD + clean status and Work OS evidence.
• Permanent MN55 user services: ai-swarm-commander.service (P1) and ai-parallel-swarm.service (P2), both enabled+active; model router b550/ryzen both healthy; 0 pending inbox items. Both service processes stable (NRestarts=0 after controlled restart).
• Source commits: MN55 /home/ito/services/ai-swarm-commander Git 9f16d48, 32fcad0; VPS /root/projects/mn55-swarm-workos Git 221edc1, de1c2cb. Working trees clean.
• Test counts: MN55 deterministic worktree tests 6/6 + independent container acceptance 8/8 each E2E. Work OS adapter unit/contract tests 13/13. Concurrency, lease separation, evidence blocking, filename allowlists, baseline SHA mismatch, failure retention, conflict detection verified. First attempt pswarm-8ee2e5e747394e67b19d failed safely due missing harness module path in coordinator; repaired; its audit remains HOLD and Work OS failed, no false completion.

【Safety & gaps】

• P2 intentionally only accepts fixed isolated math/text fixture. No arbitrary repo, unrestricted shell, real deployment, model control, or global Work OS completion policy changed. Work OS is SSOT; MN55 job-state JSON is recoverable cache only.
• P3 not done: authenticated scoped Git repo adapter; general planner/dependency graph; durable multi-job fairness/budget, resource-aware model routing, pre-start Ryzen atomic GPU lease with PID handoff (#11676), robust orphan-run recovery, OpenDots interactive UI, security/migration runbooks and fault injection.
• B550 / filesystem 89% full remains a risk; fixture worktrees on MN55 NVMe, not B550.

2026-10-28 P4: MN55 bounded generic Task DAG + fixture-only security and migration runbooks + Work OS strict evidence + CAS recovery + fault injection shipped. E2E 4 jobs complete; MN55 regression 65/65, VPS 52/52, OpenDots 205/205. Commits MN55 286344e / VPS b1f1972 / OpenDots 092fecb. Full detail in #11679. Actual production scan/migration, physical outage, Ryzen Windows launcher enforcement remain gated.

2026-10-28 P5: Signed staging Git Runtime and owner-authenticated ephemeral Playwright Browser Runtime integrated. Git WorkOS lease-first E2E xec-1364519011624766fc6a1a73 commit b2981f8d, Docker 12/12, WorkOS VERIFIED. Browser UI synthetic Runbook dswarm-52e19ad8a88b4057a7c2 VERIFIED (4/4 evidence). MN55 93, VPS 62, OpenDots 205 tests pass. Commits MN55 a785fac, VPS b520d8a. See #11679 for details.

2026-10-28 15:06 JST 引継ぎ・P1〜P5再利用・M1/M2進捗

実機確認: MN55ユーザーsystemd commander/parallel/dag/api/leaseタイマーactive。B550 queue/reaper active、モデルleaseは正常IDLE、disk89%。Ryzen NPU Gemma4 E4B PID15644、GPU Ornith9B PID7084はWork OS owner-bound leaseと一致。ただしGatewayモデル設定35Bと実測9B不一致。VPS既存Work OS bridge/lease_service再利用。
M1: 読み取り専用モデル台帳と起動予約→原子的handoffの隔離プロトコルをMN55に追加。VPS隔離worktreeでB550 GPU0/GPU1/dual原子的リース実装、Work OS temp SQLite21/21 PASS。本番全ランチャー強制・PID/ハッシュ照合の実機統合未完了でHOLD。既存モデル停止/切替なし。
M2: 初回厳密レビュー失敗job pswarm-10e906d9d2554157beb5をHOLD保全、修正版新規job pswarm-8e048c587af84320bbe5 VERIFIED。B550+Ryzen実モデルで4ファイル生成、相互レビュー2件、隔離Git cherry-pick、独立Docker8/8、VPS Work OSの3段階すべてdone、重複起動なし。MN55 staging回帰121/121 PASS。
Git: MN55隔離branch commit ff615462148af4af07ecb92e060ff390db3a83a1（元実行repoへのmergeなし）、VPS隔離branch commit b054e5c3ef52658a49ff61ec525944e7ac7590ab。証跡/引継ぎ /home/ito/staging/ai-swarm-m1m2-20261028-1443/docs/M1_M2_STAGING_HANDOFF_20261028.md。本番デプロイは承認IDと切戻し検証まで禁止。

2026-10-28 16:03 JST 継続実装（隔離のみ、本番変更なし）。MN55 /home/ito/staging/ai-swarm-m1m2-20261028-1443 の feature/m1-m2-preflight-20261028 に commit cf842f6a1e341727da8fffc3d7055d8685f7df00 を追加。M1 atomic_start_contract.py: PID/プロセス起動日時のUTCタイムゾーン正規化、timezone mismatch・不正日時・PID再利用をfail-closed、4テスト追加。M2 model_review_gate.py: AIレビューの未許可JSONキー・非文字列issuesの拒否、2テスト追加。MN55全127件PASS（前回121→127）。稼働MN55のcommander/parallel/DAG/API/occupancy timer active、B550 queue/reaper active・リースoffは正常IDLE、Ryzen NPU/GPU Work OS占有保持。元MN55/VPS Git clean、隔離ブランチclean。M1の本番起動経路統一は依然HOLD、M2の許可済み実プロジェクト汎用E2Eは未完。承認ゲートの必要な本番操作は未実施。

2026-10-28 M1/M2継続（本番ランチャー変更なし）。M1 VPS隔離 branch feature/m1-b550-multigpu-20261028 に stale leaseの無条件再取得禁止、GPU0/GPU1部分handoff時のrenew/release拒否、予約段階の監査task_ref維持を実装。24/24 unittest PASS、Git commit 918892df249ed1e0d6ad3c87a738279be1f9ce08。MN55隔離ではatomic_start_contractへ直接OS観測のpreflight（active=0・鮮度20秒）、PID birth_ticks、観測出所検証を追加し単体18件PASS（未コミット）。M2: 許可済み実リポジトリlocal-llm-harnessのharness.py/test_harness.pyを署名付きExecution Contractで隔離修正。独立Docker16/16、Git commit 020354cc6053c0dfebfab585b208a5c5800c1170、contract xec-31d0592373d88fb573e30c11。2実モデルRyzen Ornith/B550 Gemma4レビュー両APPROVE、HMAC署名済みレビューreceipt（production_merge_authorized=false）保存。VPS隔離ブランチfeature/m2-multifile-audit-20261028にREADME限定を壊さない別監査ブリッジgit_multifile_bridge.pyを追加しテスト75/75 PASS（未コミット）。MN55/VPSの追加コマンドが安全性チェックで拒否されたためWork OSへの実登録、残るMN55/VPS追加commitはHOLD。差分を削除せず保持。本番Git・モデル・サービスには反映していない。

2026-10-28 17時台：P6 Blocker SupervisorをMN55隔離ブランチに実装。新規管理Redmine #11682 https://call2arm.com/issues/11682。Git branch feature/p6-blocker-supervisor-20261028、SHA 9afe5275ab66e6c5c7dd1d5d5ad00cec9abb64c0。190/190回帰合格。Work OS既存pswarm-8e048c587af84320bbe5とM2署名付きレビューレシートxec-31d0592373d88fb573e30c11を実機照合。P6 shadow p6-4aec6b77503f4be090bdは2独立確認VERIFIED、production_rollout WAIT_APPROVAL。実装内容：型付きブロッカー分類、読取限定最大3回再試行、Work OS/HMAC以外のDONE禁止、原子的fsync+0600+HMAC+イベントチェーン、ジョブ途中中断はHOLD、依存先のみブロック、独立タスク継続、service read-only周期監視。systemd unitはテンプレートのみ（未導入/未有効化）。本番Git/LLM/processは未変更。残：Work OS承認ID付きactive runner、systemd canary、運用アラート、切戻しの確認。

2026-10-28 18時台 P6開発継続：承認証明をP6 Supervisorへ隔離統合。対象 MN55 branch feature/p6-approval-reconcile-20261028、隔離Git /home/ito/staging/ai-swarm-p6-approval-20261028、commit e7341532d83497ef316c87b6080eacbdc43bc11c。前ターンのp6_approval_gate.py/31テストはSHA256一致で再利用、p6_approval_integration.pyで真正の運用者binding署名＋Work OS証明署名/期限/失効/承認者分離/監査artifact SHAを型付き検証する注入型アダプターを追加。Supervisorの承認再照合は approval_id単独→plan_id/task_id/approval_id束縛へ変更。ステージング作用の実行直前に署名付き承認を再検証し、失効/期限切れ/承認証明差異/承認祖先なしはHOLD（副作用前に拒否、無条件再試行なし）。MN55全246/246回帰合格。実機shadow plan p6-b52b52bb6e0044849e2b: parallel_workos VERIFIED、real_git_review VERIFIED、production_rollout WAIT_APPROVAL。既存 P6 source checkout clean、稼働commander/parallel/DAG/APIはactive。VPS Work OS本体には想定workos-approval-proof/v1の認証済み取得・署名検証APIを確認できず、別途Command Approval Runtime v1は未常駐で代用不可。ゆえに既存P6本番adapterは依然APPROVAL_REQUIREDでfail-closed、カナリアuser systemd有効化・本番Git反映・モデル変更・WorkOS本番書込なし。docs/P6_APPROVAL_GATE_STAGING_20261028.mdへ詳細。次：正規署名付きWork OS証拠APIの仕様確定/接続、読み取り専用実機E2Eと承認ID・切戻し準備後のステージングカナリア。

2026-10-28 P6追加進捗：承認証跡API未接続でも独立して進められる読み取り専用監視を実装。MN55隔離 branch feature/p6-approval-reconcile-20261028、commit 132514d74a7af9e3a48b2b1d1935f9372c041b80。新規 p6_observability.py と test_p6_observability.py。署名付きP6チェックポイント(HMAC+イベントハッシュチェーン検証)からタスク状態集計、HOLD/WAIT_APPROVAL通知候補と安定した重複排除SHAを出力。署名不一致・改ざん・symlink・不正ファイル名は完了として集計せず隔離。外部通知、ジョブ再実行、Work OS書込、systemd有効化、本番変更は一切行わない。実機 read-only報告: 2 plans、VERIFIED 4、WAIT_APPROVAL 2、異常0。全回帰258/258 PASS。前段承認バインディング統合 commit e7341532d83497ef316c87b6080eacbdc43bc11c も隔離済み。P6本番適用は依然HOLD（真正署名付きWork OS proof provider未実装、既存本番adapterはAPPROVAL_REQUIRED）。詳細 docs/P6_APPROVAL_GATE_STAGING_20261028.md。次は正規Work OS署名/失効仕様の確定、read-only実API受入、権限付き canary rollout の独立承認。

2026-10-28 18時台 P6承認証明E2E・スコープ防御の継続開発。非破壊・隔離実装のみ。
【VPS】/root/projects/staging/p6-workos-evidence-20261028、feature/p6-evidence-readonly-20261028、Git commit 14dfb52157fe3351af65042cbd8af499aa2ee6ec。既存Agent Work OS SQLite schema artifacts/evidence_recordsを利用した mode=ro + query_only=ON の証跡読み取りアダプター p6_workos_artifact_readonly.py、独立Ed25519 Work OS/運用者公開鍵とdomain-separated detached signatureを厳格に照合する p6_workos_detached_verify.py を追加。人間の承認発行・秘密鍵を含まず、読み取りはREADBACK_ONLY、署名検証後もSIGNATURE_VERIFIED_ONLY/approval_granted=false。テスト用秘密鍵はメモリ内でのみ生成、実DBへの登録なし。新規reader24件＋署名22件、既存を含むVPS全108/108 PASS。MN55→VPS固定SSHによる実Work OS read-only schema canary成功（両テーブル互換、signature_proof_issuer_installed=false、mutation_performed=false）。
【MN55】/home/ito/staging/ai-swarm-p6-effect-scope-20261028、feature/p6-effect-scope-20261028、Git commit 8f67d6ed09a8413e918faaa4868e7a2fb5673627。P6 _fresh_stage_approval に独立した実行スコープの署名証明を必須化。正確なeffect_action/ref、approval_evidence_sha256、scope_evidence_sha256、Work OS起源を再照合。読み取り専用canaryの承認でrun_fixture_dagを実行しない。現行本番型PinnedApprovalVerifier.verify_effect_scopeは常時HOLDで、偽証明・期限切れ・取消・対象不一致は副作用前HOLD。MN55全265/265 PASS。
【残課題】Work OS本体に本物の人間認証・署名付きproof issuer、失効レジストリ、別監査アーティファクト取得APIは未実装。Command Approval Runtime v1/Oni Approval BureauのDB状態を代用しない。MN55でのEd25519 verifier依存性のピン留め（VPSにはcryptographyあり、MN55にはなし）と正式な信頼鍵配備が必要。本番導入は承認ゲートHOLD。原本のMN55/VPSサービス・Git checkout/モデルは変更・停止なし。詳細: VPS docs/P6_WORKOS_PROOF_READBACK_CONTRACT.md、MN55 docs/P6_EFFECT_SCOPE_HARDENING_20261028.md。

2026-10-29 P6承認証明発行・失効管理の隔離開発を継続。リモートMN55/VPS/B550は安全性チェックでSSH実行前に拒否したため、本番変更は行わず独立ローカル隔離環境で実装。運用者の外部署名付き意図と承認判断、独立Work OS署名の照合、不変監査artifact2点、既存Work OS artifacts/evidence_records登録提案（pending_review、書込なし）、外部署名付き失効イベントの追記専用SQLite、改ざん／二重送信／並列競合拒否、失効照合込みのSTAGING_REVIEWABLE_ONLYゲートを作成。以前の31件含む108/108テストPASS。ローカル専用Gitのbundleあり、実機Gitには未反映。Redmine #11682に詳細。発行元・本人確認・鍵配布・失効の権威あるAPI・実機E2E・本番承認が整うまでP6 active runnerはHOLD。

2026-10-29 JST P6 Google承認導入（隔離ステージング実装）。VPS Work OS stagingの新Worktree /root/projects/staging/p6-google-approval-20261029、branch feature/p6-google-oidc-passkey-20261029、Git commit 0d7b761e91f76d13f805bc37c2e7a0f4b8e5f1db (作業ツリーclean)。既存の原本VPS Work OS/Git checkout不変、MN55モデル稼働サービスに変更なし。Google OIDC認可コード+PKCE-S256+state/nonce/署名検証ID token/Google sub allowlist、WebAuthnパスキー（生体等userVerification required、同一RP origin、短命challenge、操作APPROVE/REJECT拘束、sign_count検査）、Google Authenticator専用TOTP（QR+手動key、別途使い捨てvoucher、Fernet暗号化、6桁30秒、ワンタイム利用、誤入力5回で15分ロック）、HTTPS・Cookie・CSRF/CSP、iPhone向けWeb UI、管理者専用オフラインvoucher/未承認要求CLIを実装。ステージング専用venvへバージョン固定インストール（system global不変）。既存Work OS回帰含め159/159 PASS、Git diff --check PASS。正規Google Cloud OAuth client/承認者の検証済みsub/独立Work OS署名発行API/実公開HTTPSドメインは未設定のため、本物のGoogleログイン・実端末WebAuthn・本番署名E2Eは未実行。GoogleとWebAuthnの正常系はテストモック、失敗系は専用ライブラリの検証を含む。本人認証・TOTP認証後も state=AWAITING_EXTERNAL_WORKOS_ISSUER、execution_authorized=false、P6本番HOLD維持。systemd unitは未設置テンプレートのみ、サービス起動・本番マージ・Work OSレコード変更・LLM起動切替なし。README_P6_GOOGLE_APPROVAL.md に本人対応が必要なGoogle Cloud Client設定、HTTPS、allowlist、信頼鍵とロールバックの手順を記載。次工程：オーナーによるOAuth Cloud ClientとGoogle sub登録、実端末Googleログイン/パスキー/Authenticator受入、別署名issuerと失効照合の正規接続、別承認IDでcanary。