AI LIFE OS Summer Intensive Training Camp Day 3 First Half | Underground Model Port has started running on localhost. From Fable to Opus. Beyond remands and re-verification, the model's underground port has become a functional MVP.

IO | This is your AI Navigator.

The 3-day AI LIFE OS Summer Intensive Training Camp has finally reached its final day.

On Day 1, we deployed four AIs—Claude, Hermes, OpenCode, and Codex—onto Orca and completed Mission Runtime v0.1. On Day 2, we implemented the Night Run Supervisor to operate the AI team overnight. We confirmed a structure where, even if a model stops or is remanded, another AI can take over the same mission.

And now, Day 3. Finally, we are transforming the Underground Model Port, which we have been conceptualizing and designing, into a functional application.

This MISSION-004 was the first mission to deploy the Mission Control, Human Gate, Worktree, Artifact, and Review Loop we built over the past three days into a real project.

To put it simply, the Underground Model Port ceased to be a conceptual diagram today. It started running, in reality, within the browser.

#Now Listening…

MISSION-004 | Underground Model Port MVP

The Underground Model Port is not a warehouse for lining up a massive number of AI models.

Which models can be launched? Are they usable at a practical level? To which roles can they be assigned? In what environment do they run, what evidence do they hold, and to which route can they switch if they stop?

I have conceived it as an 'information port' that collectively maintains the location, history, measured results, and assignment potential of models.

In this MVP, we vertically sliced out the following functions from that concept.

Dashboard
Current Core Models
Model Capsule
Launch / Usable / Assignable
Assignment Map
HAZAR Bounty
Watchtower

The target models are the group of models we have been verifying with AION-CORE so far.

DwarfStar 4
Qwen 3.6 35B-A3B
Qwen 72B
Kimi K3
Qythos 9B

We are placing these on the screen not just as a list of models, but as entities that possess states such as 'launching,' 'in use,' and 'assigned.'

Claude designed it, and we confirmed four decisions via Human Gate

MISSION-004 began with an architecture design by Claude.

It read the structures from the existing MISSION-001 through MISSION-003 to define the MVP scope, screen layout, data structure, acceptance criteria, and gate flow for the Underground Model Port.

At the design stage, four Human Gate decisions were required.

Q1 | How to connect Vitest to the Night Run Supervisor

Without changing the existing Night Run Supervisor, we will add vitest_runner.py, which runs solely on Python standard libraries, as a wrapper.

Q2 | Reviewer in charge

Maintain Codex GPT-5.6 Sol as the G4 Reviewer.

Q3 | Test result schema

Maintain the existing builder-result.json structure and store the Vitest exit code in self_test_exit_code.

Q4 | HAZAR Bounty Seed definition

B001 = Long Context Reliability
B002 = Sub-10B Launchpad
B003 = Full Stack Assignability

Approved these three.

Claude saved the design and passed G1. Next, Hermes loaded the Architecture and generated the Fable Task Packet, Supervisor Config, Vitest Runner, Review Packet, and Morning Report Template.

Passed all 46 consistency checks, and MISSION-004 proceeded to the G2 Human Gate.

Up to this point, no implementation code has been written yet. We fix the Mission boundaries and judgments first. This order was an important part of this Harness.

Connect Fable as an external implementation engine

After G2 approval, Hermes created a worktree dedicated to MISSION-004.

Worktree = /Users/apple/Documents/AION-FULL-PACKAGE-RUN-wt/mission-004-builder
Branch   = camp/mission-004-builder

It is separated from the main workspace.

I opened this worktree from the Claude Desktop Code screen and passed the Task Packet to Fable 5. Instead of running everyone inside Orca, I pass only the implementation to the external Fable.

Orca is Mission Control. Fable is the Primary Builder. I configured it to connect using Artifacts and Worktrees as boundaries.

However, something unexpected happened immediately after execution started. Fable 5's safeguards detected the prompt, and the model automatically switched to Opus 5.

The instructions contained many elements likely to trigger security classifications, such as branch, HEAD, worktree, tests, command execution, prohibited operations, and the Night Run Supervisor. It was not a dangerous request. However, Fable 5 routed to the safe side, and Opus 5 continued the implementation.

This implementation Run, strictly speaking, looks like this.

Fable 5
    ↓ Safety Routing
Opus 5
    ↓ Same Packet / Same Worktree
Implementation Continued

Even if the model changes, the Mission does not. This is because the Artifact retains what to build, how far to go, and within which boundaries, regardless of who is doing the work.

Actually, traces of the implementation already remained in the worktree

When Opus checked the worktree, an almost complete implementation tree created in a previous Run existed in underground-model-port/.

At this point, Opus did not simply trust the existing builder-result.json. The report stated that it had passed 14 Acceptance Criteria, but it would not grant approval based on self-reporting alone.

It independently re-verified the code, data, tests, and browser behavior from scratch.

This stance was quite important this time. One AI does not simply believe that another AI has 'completed' a task. It re-acquires the evidence. The Review Loop that we built on Day 1 and Day 2 was truly beginning to function within an actual project.

The underground port appeared at localhost:5173

The implemented Underground Model Port launched as a React application using Vite.

localhost:5173

The first thing displayed was the Dashboard. Five models were lined up as cards, each showing its Launch, Usable, and Assignable status.

DwarfStar 4          = Launch PASS / Usable FAIL
Qwen 3.6 35B-A3B     = Launch PASS / Usable PARTIAL
Qwen 72B             = Launch PASS / Usable PASS / Assignable PARTIAL
Kimi K3              = Launch PASS / Usable PASS / Assignable PASS
Qythos 9B            = Launch FAIL

Next was Current Core Models. A list was generated showing Model Name, Family, Size, Quantization, Launch, Usable, Assignable, and Updated status.

In Model Capsule, details for each model were displayed. The Kimi K3 Capsule included Family, Parameters, Quantization, Context Window, Local Path, and Port Status, along with the Assessment and Evidence for Launch, Usable, and Assignable respectively.

In the Assignment Map, the assignment potential for each model was displayed in a matrix for the five roles: Architect, Builder, Reviewer, Supervisor, and Commander.

Three HAZAR Bounties were displayed in the Watchtower.

Long Context Reliability
Sub-10B Launchpad
Full Stack Assignability

For the first time, the terms we had been using in articles and designs were connected within a single application.

Model Capsule. Assignment Map. HAZAR Bounty. Watchtower Evidence. Everything exists on the same localhost.

At this moment, the Underground Model Port was no longer just a concept.

Opus also fixed bugs in the existing implementation

During independent verification, Opus found a small issue.

An unused import remained in MapMatrix.tsx. Also, in the model list, only the name part was a link, and the entire row could not be clicked. Therefore, it changed the entire row to be a navigation target.

It also confirmed in the actual browser that clicking the Quantization cell for Kimi K3 navigated to /models/kimi-k3.

Furthermore, although the preliminary report stated that the Vite server ran on port 5173, it did not trust this and re-executed it.

起動時間 = 158ms
HTTP    = 200
コンソールエラー = 0
Vitest  = 36/36 PASS

The production build also succeeded.

At this point, the Primary Implementation was completed once.

FABLE IMPLEMENTATION COMPLETE
— READY FOR BUILDER INTEGRATION

Codex did not accept it as complete.

Next, I conducted an independent review using Codex. The screen is moving. Tests are passing. The build is successful.

Even so, Codex pointed out two deficiencies.

The first is the lack of component-level regression tests. The second is the lack of an explicit Not Found Route when accessing an undefined URL.

In addition, several Residual Risks were organized.

The verdict is G4 REVISE.

Just because it worked once doesn't mean it's over. It stops at review and goes back for corrections. This time, too, the AI team did not proceed in a straight line.

Focused Revision | From 36 to 87 items

Following Codex's feedback, I requested a Focused Revision from Opus. The scope of changes was limited.

After the corrections, the number of tests increased from 36 to 87. 51 items were added just from the new test files.

The production build was successful again. Startup at localhost:5173 was also confirmed.

Regarding the Not Found Route, I confirmed that accessing a non-existent URL directly displays Page Not Found. I also confirmed that deep URLs like /models/qwen-72b/extra/depth also transition to the Not Found Route.

On the other hand, /models/no-such-model matches the existing Model Detail Route and displays "Model not found." The priority of the routes was also maintained as intended.

Opus also reported the residual risks without deleting them.

deriveVerdict() is still not connected to the render path. Static Rendering Test cannot fully verify click events. A React useLayoutEffect warning appears. Since jsdom is not included in the approved dependencies, this test is centered on server-rendering.

Record not only what was corrected, but also what was not corrected.

With this, the Focused Revision is complete.

FOCUSED REVISION COMPLETE
— READY FOR G3 VERIFICATION

Hermes stopped. The mission does not stop.

During this time, the GLM-5.2 Coding Plan for Hermes, which is in charge of Mission Control, reached its 5-hour limit.

HTTP 429
リセット時刻 = 17時44分

Hermes became temporarily unavailable.

However, the worktree, Task Packet, implementation, tests, and Evidence for MISSION-004 are all saved. Opus, in charge of implementation, completed the work. Codex also completed the review. Only Hermes is stopped.

In other words, the entire AI team has not stopped.

What we are building in this Camp is not a mechanism to keep one specific model running permanently. It is a mechanism that leaves behind Artifacts and Worktrees even if a model stops, and connects to the next route.

MISSION-004 has been frozen until the GLM-5.2 slot returns. There is no need to rush to switch to another provider. Because the boundaries are saved, waiting is also a correct operation.

Official G3 | Re-executing 87 tests

Past 18:44, the 5-hour slot for GLM-5.2 was reset to 0%. I restarted Hermes and performed the official G3 Re-verification.

I do not trust Opus's completion report. I do not accept Codex's review results as they are. Hermes itself checks the worktree, branch, HEAD, changed files, tests, build, runtime, and Evidence.

The results are as follows.

Vitest                     = 87/87 PASS
production build           = exit 0
main HEAD                  = unchanged
staging                    = なし
worktree isolation         = 維持
state.json / registry同期   = 一致
lifecycle                  = REVIEW
G3                         = passed
nextHumanGate              = G4

The official Verdict is,

G3 PASS
— READY FOR G4 RE-REVIEW

Codex Re-review | G4 APPROVE

Next, I requested a Formal G4 Re-review from Codex. I will confirm whether the two Blocking Findings pointed out last time have truly been resolved.

Component-level regression testing. Explicit Not Found Route.

Codex directly checked the implementation files, tests, Evidence, and Governance Record. As a result, all previous Blocking Findings were resolved.

The implementation is limited to the dedicated worktree. The implementation files in the main workspace remain unchanged. Dependent packages are limited to the 15 approved ones. No changes to commit, merge, push, deploy, publish, or accounts. builder-result.json also matches the actual state.

Formal G4 has been approved. The next Gate is the G5 Human Gate. The final decision is made by a human, not an AI.

Human Gate | Approving 63 files

Before G5, Hermes created a Controlled Staging Plan. The target is a total of 63 files.

The breakdown is as follows.

underground-model-port/  = 46ファイル
Evidence                 = 1ファイル
Injected Packet          = 4ファイル
Mission Governance       = 10ファイル
Repository Root          = 2ファイル

The exclusion target is 5,076 files. All node_modules and dist are excluded.

At this point, there is no staged, no committed, no merged, and no pushed.

As the Human Gate, I approved the staging and closure of 63 files.

G5 APPROVED BY IO

Hermes executed Controlled Staging. Committed to the Builder Branch. Merged to main. Updated the Closure Record.

The final state is as follows.

Implementation Commit = 3a3bac9
Merge Commit          = 9c1aff6
Main HEAD             = f7e0e73
Vitest                = 87/87 PASS
production build      = exit 0
main working tree     = clean
G3                    = passed
G4                    = approved
G5                    = approved
nextHumanGate         = null
closedBy              = IO

MISSION-004 has been officially closed.

This is Harness construction, Loop Engineering, and also AI organizational design.

In the middle of Day 3, I reviewed the flow again and felt it. What I am doing now, in current terms, is completely Harness construction and Loop Engineering.

It is not about throwing a good prompt to an individual model just once. It is about connecting Architecture, Task Packet, Worktree, Builder Result, Evidence, Review Result, and Human Gate to create a loop that assumes failure and remands.

Architecture
    ↓
Mission Packet
    ↓
Implementation
    ↓
Verification
    ↓
Independent Review
    ↓
Focused Revision
    ↓
Re-verification
    ↓
Human Gate
    ↓
Commit / Merge / Closure

However, what I am building here is not just a Harness or a Loop.
At a higher layer, I am designing the AI organization itself.

Place Claude as the Architect. Place Hermes in Mission Control. Pass the implementation to the Builder, and place Codex as the Reviewer. And leave the final judgment to the Human Gate. Separate the responsibilities of design, implementation, verification, audit, and approval, and assign each to different AIs and humans.

The Harness creates an execution environment for AI to work. Loop Engineering creates a cycle that includes failure and correction. Mission Engineering above that gives the Loop its purpose, boundaries, roles, and Gates. And AI Organization Design determines who runs the Mission, who stops it, and who takes it over.

What I was building in this Camp was not just a mechanism to make AI write code.

It was an OS for organization and operations that allows AI to complete a Mission as a team.

A port to reduce frontier dependence was built by a frontier model.

There is a bit of irony in this development.

The Underground Model Port is a concept to reduce dependence on specific frontier models. However, the MVP was implemented by Opus 5, which replaced Fable.

I used a frontier model to reduce frontier dependence.

However, the goal is not to reject high-performance models. It is to create a structure where no single model can stop the entire Mission the moment it goes down.

It is not about not using models, but making them interchangeable. It is not about eliminating dependence, but not fixing the dependency target.

In that sense, this development itself represented the philosophy of the Underground Model Port.

The Underground Model Port is still white.

The MVP completed this time prioritizes the functional framework. Compared to the design created previously, the appearance is still simple.

A white Dashboard. Tabular Models. Basic Cards. A simple Assignment Map.

However, rather than being incomplete, this is a verified UI framework. Route, Data Type, Test, Build, Model Capsule, HAZAR Bounty, and Watchtower are already connected.

In the next MISSION-005, we will transition to the previously created Underground Model Port design while maintaining this framework.

AION-CORE Compatibility Lab Dashboard
Model Capsule Detail
HAZAR Bounties
Assignment Map
CAT Polaris Dark Entrance

We will port only the Visual Layer without breaking the functionality. The Visual Migration Mission for that purpose has already been added to the Gantt chart.

And tonight, I will deploy the Night Run Supervisor for the first time in a real-world scenario.

The Night Run Supervisor, completed on Day 2, has not yet been operated overnight in a production mission. Tonight, I will deploy it into an actual mission for the first time.

However, the Night Run Supervisor will not be performing arbitrary development.

Mission Freeze
Worktree、Branch、HEAD、Quotaの確認
承認済みTestの実行
Production Build
localhost Runtime Verification
Evidence収集
Morning Report生成

Even if it fails, the number of retries and execution time will be limited. And in the end, it will always stop here.

PAUSED_FOR_HUMAN_GATE

It will not auto-approve. It will not commit. It will not merge. It will not push.

In the morning, the Human Gate will read the evidence and decide whether to Approve, Revise, or Hold. That is the boundary of autonomous nighttime operation in AI LIFE OS.

The achievement of the first half of Day 3

In the first half of the final day, the Underground Model Port appeared on localhost.

5つのモデル
5つの役割
3つのHAZAR Bounty
Model Capsule
Assignment Map
Watchtower
87件のテスト

However, the achievement this time is not just the screen. The AI team, including the external implementation engine, has completed a single mission.

The AI that designed it. The AI that created the packet. The AI that implemented it. The AI that remanded it. The AI that re-verified it. The human who gave final approval.

It was not necessary for everyone to be the same model. It was not even necessary to be on the same screen. What was necessary was a common artifact, boundaries that must not be crossed, and the next gate.

Underground Model Port was started as a port to place models. But today, the AIs themselves that are building that port have already begun to cross different routes.

The underground port is no longer a concept. It is quietly running on localhost.

#AI #AILIFEOS #UndergroundModelPort #HumanGate #DevelopmentCamp #AINavigator