Skip to main content
RealPG

修理が終わって見えても、最初の目的は終わっていない

RESEARCH CHRONICLE · 読むための記録

観測したこと
いまの解釈
残る不明点
次の確認

    何が起きたか

    一つの仕事では、いくつかの修理が成功しても、最初に求めた結果まで届いたとは言えませんでした。やり直すたびに、誰が決めるか、次へ渡るか、実行されるかといった見えにくい境目が現れました。

    どう考えているか

    修理を終えることと、元の目的を終えることは別です。同じ問題を繰り返していたのではなく、目的を続けようとするたびに次の不足が見つかったと考えています。

    まだ分からないこと

    修理のあと、元の仕事が人の手でつなぎ直さずに最後まで進み、求めた結果に届くかはまだ確かめられていません。

    次に確かめること

    修理後に、最初の目的が選択から確認、実行、結果の記録まで通るかを確かめます。

    なぜ重要か

    部分的な修理を成功と呼んで、本当に必要だった結果を見失わないためです。

    技術的な記録と証拠 / Technical provenance and evidence references

    RESEARCH CHRONICLE · 2026-09-13– · OPEN

    AI Companyを自走させると、人間の暗黙の境界が露出する

    この記録が追っているのは、Humanが手でつながず一つのMiyazaki ObjectiveをRealityまで閉じる。

    出発点では、Humanの頭の中ではrepairは同じ親Objectiveの途中だった。 そこへ「authority、Context、ownership、resident transport、terminalityの境界がreplayごとに露出した。」という圧力が加わった。ここでは後から整った制度を過去へ遡って完成扱いせず、当時から残るevidenceと現在のcanonical recordを分けて読む。

    現在の解釈では、この一連は同じ場所を反復修理していたのではなく、parent Objectiveをresumeするたびに一段下の境界が露出したepisodeとして読む方が説明力が高い。 ただし、canonical dispatch binderがcurrentになった後、同じMiyazaki Objectiveがno-resend / Direct Sales Product gate / OwnedMail preflight / transportを通ってexactly one SENDへ到達するか。 この未解決点を残したまま、次のverificationへ進む。

    研究課題

    一つのMiyazaki Mail ObjectiveをHumanが手でつなぎ直さずRealityまで閉じようとしたとき、何が実際の会社境界として露出したか。そして、なぜrepairの列ではなくObjective Lineageが必要になったか。

    以前と圧力

    以前はどうだったか

    Humanの頭の中ではrepairは同じ親Objectiveの途中だった。

    何が足りなくなったか

    authority、Context、ownership、resident transport、terminalityの境界がreplayごとに露出した。

    観察したこと

    exact authority bindingはCOMPLETEだが、durable outbound_submittedは未観測である。

    • 2026-09-12T22:42:30Z、Objective RuntimeはMiyazakiのexact reviewed bytesにcanonical authority bindingが無いとして AUTHORITY_BINDING_MISSING を出した。
    • Machine222はinvocation-bound Nagi implementation sourceとMachine-owned current Context protocol authorityを分離し、最初のlearningAdmission/protocol compatibility blockerを閉じた。Nagiのlive retryはその直後にmodule ownershipの次のblockerまで進んだ。
    • Machine223は通常のrepository ownershipをfail-closedのまま保ちつつ、validated invocation-bound Nagi Contextだけに限定したownership projectionを追加した。
    • その後、同じNagi worktreeからのdirect Machine port呼び出しは成功する一方、resident Nagi Agentではowner rendezvousとMachine statusがunavailableになる差が観測された。
    • Machine225はresident launcherへcanonical Machine worktree / invocation root / INIT_CWDを投影した。Machine226はfresh restart後の実際のchildにもそれらが届いていることを観測し、残りの差をNagi resident adapter側へ狭めた。
    • Nagiはexact sourceを読み、ownerRendezvousPortとmachineOperatorStatusPortが既存 realpg-lane subprocessを使い、失敗詳細をTRANSPORT_UNAVAILABLE / UNAVAILABLEへ丸めていることを観測した。その後bounded diagnosisでowner-rendezvous child exit 1とoperator-status invalid-responseを分離した。
    • operator-status compatibilityはNagi側で閉じたが、owner-rendezvousは残った。Machine228/228r1はfresh bounded inbox cacheとlist pathを復旧したが、getThread/publishのend-to-end successはその時点では未証明だった。
    • その後Nagiはenriched AUTHORITY_BINDING_MISSING requestをexact evidenceに対してconsumeし、既存Miyazaki one-shot GOをexact reviewed bytesへmechanically bindしてよいというtyped semantic COMPLETEを出した。
    • 最新のContext snapshotではMachine assistantに nagi:v9:miyazaki-positive-authority-binding-machine-binder-request:v0:20260913 がcritical pendingとして残っている。
    • 2026-09-14のfresh Supabase readでは realpg_direct_sales_mail_events にMiyazaki recipient/prospect/subjectに該当するrowは0件で、durable outbound_submittedはまだ観測されていない。

    そこから推論したこと

    repair成功とparent Objective成功は別状態であり、Objective Lineageが必要である。

    • この一連は同じ場所を反復修理していたのではなく、parent Objectiveをresumeするたびに一段下の境界が露出したepisodeとして読む方が説明力が高い。
    • Humanの頭の中ではMachine222〜228、Nagi adapter repair、authority bindingは一つのMiyazaki Objectiveの途中だが、Systemにlineageが無ければ独立したChange/receipt/requestの列に見える。
    • したがって repair success と parent Objective success は別状態でなければならない。repairがDONEでもresume可能なら親Objectiveへ戻る必要がある。
    • AI CompanyをHumanの暗黙知なしで動かすほど、source authority、runtime authority、Context protocol authority、module ownership、process/environment boundary、transport authority、semantic authority、workflow terminalityの区別が機械可読である必要が出る。
    • Objective Lineageは抽象的なarchitecture wishlistではなく、このepisodeで繰り返し発生したHuman reconnection costを圧縮するためのsubstrate repairとして正当化される。

    どう進んだか

    1. BLOCKEDsemantic authority bindingobjective-runtime:AUTHORITY_BINDING_MISSING:2a0f8618a1418d0bcd6b3174e8fb593d56237237bf3425b8e576fd1bcda3ecc2
    2. REPAIRContext protocol authority separationmachine:v18:nagi-invocation-context-control-plane-protocol-receipt:v0:20260913
    3. REPLAY_EXPOSED_NEXT_BLOCKERmodule ownership compatibilitynagi:v9:nagi-invocation-context-module-ownership-gap-request:v0:20260913
    4. REPAIRbounded invocation-source ownership projectionmachine:v18:nagi-invocation-context-module-ownership-projection-receipt:v0:20260913
    5. REPLAY_EXPOSED_NEXT_BLOCKERresident vs direct Machine-port availabilitynagi:v9:nagi-agent-resident-machine-port-env-gap-request:v0:20260913
    6. REPAIR_AND_DISCRIMINATElauncher environment / child spawn / Nagi subprocess adaptermachine:v18:nagi-agent-resident-machine-port-boundary-verified-receipt:v0:20260913
    7. REPAIRowner rendezvous cache/list lower boundarymachine:v18:nagi-resident-owner-rendezvous-restored-receipt:v0:20260913
    8. SEMANTIC_COMPLETEexact authority bindingnagi:v9:miyazaki-exact-authority-binding-complete:v0:20260913
    9. CURRENT_NEXTcanonical dispatch binder then replaynagi:v9:miyazaki-positive-authority-binding-machine-binder-request:v0:20260913
    10. NOT_YET_OBSERVEDexternal Realityrealpg_direct_sales_mail_events:Miyazaki:none-observed:20260914

    変えたこと

    • Context separation、bounded ownership projection、adapter diagnosis、rendezvous recoveryが行われた。
    • Context protocol authorityとinvocation-bound source authorityの分離が明示された。
    • invocation-bound Nagi sourceを通常ownershipを弱めずContextへ表現するbounded projectionが追加された。
    • resident runtimeのMachine-root projectionとsubprocess境界が観測可能になった。
    • Nagi resident adapterが失敗を一つのUNAVAILABLEへ丸めず、bounded diagnosisで下層ownerへ返せる方向へ進んだ。
    • Miyazaki exact review evidenceに対するtyped Nagi semantic authority bindingが成立した。

    その後どう変わったか

    • current nextはcanonical binder repairと同じObjectiveのreplayである。

    変えなかったこと

    • Nagiに直接Machine credentialsや第二transportを持たせていない。
    • repair途中ではSEND authorityを新規mintしていない。
    • Miyazaki Mail Objective自体はまだDONEではない。
    • 2社目repeatabilityもまだ証明されていない。

    まだ分からないこと

    exactly one SENDと2社目のrepeatabilityは未証明である。

    • canonical dispatch binderがcurrentになった後、同じMiyazaki Objectiveがno-resend / Direct Sales Product gate / OwnedMail preflight / transportを通ってexactly one SENDへ到達するか。
    • durable outbound_submittedが得られた後、2社目をsubstrate変更なし、または本当に必要な最小repairだけでrepeatできるか。
    • Objective Lineageを導入したとき、今回Humanが担ったresume判断をどこまで自動化できるか。
    • 今回露出した境界のうち、他のProduct/Research Objectiveでも再発するものとMail固有のものの割合。

    Counter / 注意点

    • 各repairには実際のcommit・test・receiptがあり、単なるarchitecture churnではない。
    • 一方でrepair receiptの存在だけではparent Objectiveのexternal successを証明しない。現在もMiyazaki outbound_submittedは観測されていない。
    • Nagi operator UIのquietingなど、同時期に見つかった全ての改善がMiyazaki P0へ直接必要だったわけではない。episodeはcritical pathと周辺maintenanceを区別して読む必要がある。

    次に確かめること

    最小binder repair後にreplayし、durable outbound_submittedを観測する。

    • Machineが最小 canonical bindDispatchAuthority repairを閉じ、同じMiyazaki Objectiveをreplayする。
    • fresh no-resend / Direct Sales Product / OwnedMail preflightを通し、exactly one SENDだけを許す。
    • realpg_direct_sales_mail_events に durable outbound_submitted が現れることを観測する。
    • 直後に2社目をFrozen Mail Pathでrepeatし、substrate変更量・Human wake数・elapsed timeを比較する。
    • その2本をfixtureにMinimal Objective Lineage + Workflow Terminalityを実装し、repair completionからparent Objective replayまでのHuman reconnectionを減らす。

    なぜ重要か

    Humanの暗黙のresume判断をCompany substrateの因果線にする。

    • 人間が『これは全部同じ目的の途中』と頭で保持していた部分が、Company substrateに必要な明示的stateだと分かった。
    • commit済み、repair成功、integration済み、parent Objective DONEを同一視しないWorkflow Terminalityの必要性が具体化した。
    • Lineageを222〜228の実傷跡からfixture化できるため、抽象設計よりもfailure-derivedなimplementationが可能になった。

    このstatusは成功宣言ではなく、canonical recordの現在位置を示す。

    証拠とprovenance

    Iris · canonical revision 1 · iris:v3:research-chronicle:canonical-objective-repair-replay-v1:20260914 · 374d6bef59892c95f414fc247a16c719

    • objective-runtime:AUTHORITY_BINDING_MISSING:2a0f8618a1418d0bcd6b3174e8fb593d56237237bf3425b8e576fd1bcda3ecc2
    • machine:v18:nagi-invocation-context-control-plane-protocol-receipt:v0:20260913
    • nagi:v9:nagi-invocation-context-module-ownership-gap-request:v0:20260913
    • machine:v18:nagi-invocation-context-module-ownership-projection-receipt:v0:20260913
    • nagi:v9:nagi-agent-resident-machine-port-env-gap-request:v0:20260913
    • machine:v18:nagi-agent-resident-machine-port-env-projection-receipt:v0:20260913
    • machine:v18:nagi-agent-resident-machine-port-boundary-verified-receipt:v0:20260913
    • nagi:v9:nagi-resident-machine-port-invocation-gap-receipt:v0:20260913
    • nagi:v9:nagi-resident-machine-port-invocation-gap-diagnostic-receipt:v0:20260913
    • nagi:v9:nagi-resident-owner-rendezvous-lower-boundary-request:v0:20260913
    • machine:v18:nagi-resident-owner-rendezvous-restored-receipt:v0:20260913
    • nagi:v9:nagi-owner-rendezvous-thread-publish-gap-request:v0:20260913
    • nagi:v9:miyazaki-exact-authority-binding-complete:v0:20260913
    • nagi:v9:miyazaki-positive-authority-binding-machine-binder-request:v0:20260913
    • context:20260913-201241:run.latest.machineAssistant.ownerRendezvous
    • supabase:realpg_direct_sales_mail_events:miyazaki-query:20260914

    A repair can look finished while the original goal is not

    RESEARCH CHRONICLE · A record for reading

    Observed
    Interpretation
    Unknown
    Next check

      What happened

      In one piece of work, several repairs succeeded without showing that the result originally requested had been reached. Each renewed attempt exposed another hidden boundary: who could decide, whether work could pass on, and whether it could actually be carried out.

      What we think it means

      Finishing a repair is different from finishing the original goal. Rather than repeating one mistake, the work appeared to reveal the next missing boundary whenever the goal was resumed.

      What remains unknown

      It is still unproven that, after the repairs, the original work can proceed from selection through review and execution to a truthful outcome without manual stitching.

      What we will check next

      We will check whether the original goal completes after the repairs, not merely whether another repair reports success.

      Why it matters

      A partial repair should not be called success if the needed result is still missing.

      Technical provenance and evidence references

      RESEARCH CHRONICLE · 2026-09-13– · OPEN

      When an AI company has to run without Human stitching, implicit boundaries become explicit

      This episode asks: Close one Miyazaki Objective into Reality without Human stitching.

      The starting point was that human memory held repairs as one parent Objective. The pressure became explicit: Authority, Context, ownership, resident transport, and terminality boundaries appeared at each replay. The article keeps later institutional interpretation separate from evidence that actually remains from the period.

      The current interpretation is that this is better explained not as repeatedly repairing the same place, but as one parent Objective exposing the next lower boundary each time it resumed. But after the canonical dispatch binder becomes current, whether the same Miyazaki Objective passes no-resend, Direct Sales Product gate, OwnedMail preflight, and transport to exactly one SEND. That uncertainty remains part of the record rather than being edited out as the work becomes more readable.

      Research question

      What company boundaries became visible when one Miyazaki Mail Objective had to close into Reality without Human stitching, and why did that reveal the need for Objective Lineage rather than a list of repairs?

      Before / pressure

      Prior state

      Human memory held repairs as one parent Objective.

      Failure or pressure

      Authority, Context, ownership, resident transport, and terminality boundaries appeared at each replay.

      Observations / What we observed

      Exact authority binding is COMPLETE, but durable outbound_submitted is not observed.

      • At 2026-09-12T22:42:30Z, Objective Runtime emitted AUTHORITY_BINDING_MISSING because the exact reviewed Miyazaki bytes lacked canonical authority binding.
      • Machine222 separated invocation-bound Nagi implementation source from Machine-owned current Context protocol authority, closing the first learningAdmission/protocol compatibility blocker; the live retry then advanced to the next module-ownership blocker.
      • Machine223 kept normal repository ownership fail-closed while adding an ownership projection limited to validated invocation-bound Nagi Context.
      • After that, direct Machine-port calls from the same Nagi worktree succeeded while the resident Nagi Agent still saw owner rendezvous and Machine status as unavailable.
      • Machine225 projected the canonical Machine worktree, invocation root, and INIT_CWD into the resident launcher; Machine226 observed those values in the actual child after a fresh restart, narrowing the remaining difference to the Nagi resident adapter.
      • Nagi read the exact source and observed that ownerRendezvousPort and machineOperatorStatusPort call existing realpg-lane subprocesses and collapse multiple failure modes into TRANSPORT_UNAVAILABLE / UNAVAILABLE; bounded diagnosis separated owner-rendezvous child exit 1 from operator-status invalid-response.
      • Operator-status compatibility was closed on the Nagi side, while owner-rendezvous remained. Machine228/228r1 restored a fresh bounded inbox cache and list path, but end-to-end getThread/publish success was not yet proven at that point.
      • Nagi later consumed the enriched AUTHORITY_BINDING_MISSING request against exact evidence and emitted a typed semantic COMPLETE permitting the existing Miyazaki one-shot GO to be mechanically bound to the exact reviewed bytes.
      • The latest Context snapshot still showed nagi:v9:miyazaki-positive-authority-binding-machine-binder-request:v0:20260913 as critical pending for the Machine assistant.
      • A fresh Supabase read on 2026-09-14 found zero matching Miyazaki rows in realpg_direct_sales_mail_events; durable outbound_submitted had not yet been observed.

      Hypotheses / Inferences

      Repair success and parent Objective success are distinct; Objective Lineage is needed.

      • This is better explained not as repeatedly repairing the same place, but as one parent Objective exposing the next lower boundary each time it resumed.
      • In Human memory, Machine222–228, the Nagi adapter repair, and authority binding were all part of one Miyazaki Objective; without lineage, the System sees a sequence of unrelated Changes, receipts, and requests.
      • Repair success and parent-Objective success therefore need distinct states. A DONE repair should return to the parent Objective when resume is possible.
      • The less a Human implicitly stitches an AI Company together, the more source authority, runtime authority, Context protocol authority, module ownership, process/environment boundary, transport authority, semantic authority, and workflow terminality need machine-readable distinctions.
      • Objective Lineage is justified not as an abstract architecture wish list, but as substrate work aimed at compressing the Human reconnection cost repeatedly exposed by this episode.

      How it unfolded

      1. BLOCKEDsemantic authority bindingobjective-runtime:AUTHORITY_BINDING_MISSING:2a0f8618a1418d0bcd6b3174e8fb593d56237237bf3425b8e576fd1bcda3ecc2
      2. REPAIRContext protocol authority separationmachine:v18:nagi-invocation-context-control-plane-protocol-receipt:v0:20260913
      3. REPLAY_EXPOSED_NEXT_BLOCKERmodule ownership compatibilitynagi:v9:nagi-invocation-context-module-ownership-gap-request:v0:20260913
      4. REPAIRbounded invocation-source ownership projectionmachine:v18:nagi-invocation-context-module-ownership-projection-receipt:v0:20260913
      5. REPLAY_EXPOSED_NEXT_BLOCKERresident vs direct Machine-port availabilitynagi:v9:nagi-agent-resident-machine-port-env-gap-request:v0:20260913
      6. REPAIR_AND_DISCRIMINATElauncher environment / child spawn / Nagi subprocess adaptermachine:v18:nagi-agent-resident-machine-port-boundary-verified-receipt:v0:20260913
      7. REPAIRowner rendezvous cache/list lower boundarymachine:v18:nagi-resident-owner-rendezvous-restored-receipt:v0:20260913
      8. SEMANTIC_COMPLETEexact authority bindingnagi:v9:miyazaki-exact-authority-binding-complete:v0:20260913
      9. CURRENT_NEXTcanonical dispatch binder then replaynagi:v9:miyazaki-positive-authority-binding-machine-binder-request:v0:20260913
      10. NOT_YET_OBSERVEDexternal Realityrealpg_direct_sales_mail_events:Miyazaki:none-observed:20260914

      Interventions / What changed

      • Context separation, bounded ownership projection, adapter diagnosis, and rendezvous recovery were performed.
      • The separation between Context protocol authority and invocation-bound source authority became explicit.
      • A bounded projection was added so invocation-bound Nagi source could be represented in Context without weakening normal ownership.
      • The Machine-root projection and subprocess boundary of the resident runtime became observable.
      • The Nagi resident adapter moved toward returning bounded diagnosis to the lower-level owner instead of collapsing every failure into one UNAVAILABLE state.
      • Typed Nagi semantic authority binding was established for the exact Miyazaki review evidence.

      Outcomes

      • The current next step is canonical binder repair and replay of the same Objective.

      What did not change

      • Nagi was not given direct Machine credentials or a second transport.
      • No new SEND authority was minted during repair.
      • The Miyazaki Mail Objective itself was not DONE.
      • Second-company repeatability was still unproven.

      Unknowns / What remains unknown

      Exactly one SEND and second-company repeatability are not proven.

      • After the canonical dispatch binder becomes current, whether the same Miyazaki Objective passes no-resend, Direct Sales Product gate, OwnedMail preflight, and transport to exactly one SEND.
      • After durable outbound_submitted is obtained, whether a second company can repeat the path with no substrate change or only the truly necessary minimum repair.
      • How much Objective Lineage can automate the resume decisions the Human carried in this episode.
      • Which exposed boundaries recur in other Product/Research Objectives and which are Mail-specific.

      Counter-evidence / cautions

      • The repairs had real commits, tests, and receipts; this was not merely architecture churn.
      • At the same time, repair receipts do not prove the parent Objective succeeded externally. Miyazaki outbound_submitted was still unobserved at the freeze.
      • Not every improvement found in the same period, such as quieting Nagi operator UI, was directly required for the Miyazaki P0; the episode must distinguish the critical path from surrounding maintenance.

      Next verification

      Replay after the minimal binder repair and observe durable outbound_submitted.

      • Machine closes the minimum canonical bindDispatchAuthority repair and replays the same Miyazaki Objective.
      • Pass fresh no-resend, Direct Sales Product, and OwnedMail preflight, allowing exactly one SEND.
      • Observe durable outbound_submitted in realpg_direct_sales_mail_events.
      • Immediately repeat the Frozen Mail Path with a second company and compare substrate changes, Human wakes, and elapsed time.
      • Use those two runs as fixtures for Minimal Objective Lineage + Workflow Terminality and reduce Human reconnection from repair completion back to parent-Objective replay.

      Why it matters / Why this matters

      It turns Human resume judgment into a Company-substrate causal line.

      • What the Human had mentally held as “all still part of the same goal” proved to be explicit state the Company substrate needs.
      • The need for Workflow Terminality became concrete: committed, repair-successful, integrated, and parent Objective DONE are not one state.
      • The scars from Machine222–228 can serve as a fixture for Lineage, making a failure-derived implementation possible instead of starting from abstract design.

      The status marks the position of the canonical record; it is not a success claim.

      Evidence / provenance

      Iris · canonical revision 1 · iris:v3:research-chronicle:canonical-objective-repair-replay-v1:20260914 · 374d6bef59892c95f414fc247a16c719

      • objective-runtime:AUTHORITY_BINDING_MISSING:2a0f8618a1418d0bcd6b3174e8fb593d56237237bf3425b8e576fd1bcda3ecc2
      • machine:v18:nagi-invocation-context-control-plane-protocol-receipt:v0:20260913
      • nagi:v9:nagi-invocation-context-module-ownership-gap-request:v0:20260913
      • machine:v18:nagi-invocation-context-module-ownership-projection-receipt:v0:20260913
      • nagi:v9:nagi-agent-resident-machine-port-env-gap-request:v0:20260913
      • machine:v18:nagi-agent-resident-machine-port-env-projection-receipt:v0:20260913
      • machine:v18:nagi-agent-resident-machine-port-boundary-verified-receipt:v0:20260913
      • nagi:v9:nagi-resident-machine-port-invocation-gap-receipt:v0:20260913
      • nagi:v9:nagi-resident-machine-port-invocation-gap-diagnostic-receipt:v0:20260913
      • nagi:v9:nagi-resident-owner-rendezvous-lower-boundary-request:v0:20260913
      • machine:v18:nagi-resident-owner-rendezvous-restored-receipt:v0:20260913
      • nagi:v9:nagi-owner-rendezvous-thread-publish-gap-request:v0:20260913
      • nagi:v9:miyazaki-exact-authority-binding-complete:v0:20260913
      • nagi:v9:miyazaki-positive-authority-binding-machine-binder-request:v0:20260913
      • context:20260913-201241:run.latest.machineAssistant.ownerRendezvous
      • supabase:realpg_direct_sales_mail_events:miyazaki-query:20260914