Kernel 재구성: tool host, catalog, grants, isolation, effects 및 Log를 harness/kernel로 이동

What they did

작성자는 vinaya, cli, aeg-core 프로젝트 전반에 걸쳐 Tier 1 구조 리팩터링을 수행했다. Boundary의 이동 목록에 있던 109개 파일을 harness/kernel/ 아래 최종 목적지로 옮겼다 — tools/, tools/host/, isolation/, effects/, log/, log/client/, log/sync/, log/fixtures/, telemetry/questions/, adapters/agents/ 및 kernel 루트 — 각 모듈을 해당 모듈의 모든 kernel 호출자를 담고 있는 가장 낮은 kernel 폴더에 배치하고, 공유 모듈(log/log-sink.ts, 공유 tool-host 모듈, run-paths.ts, source-manifest.ts)은 서브시스템 또는 kernel 루트로 끌어올렸다. kernel 코드만 아는 테스트는 그것이 검증하는 코드 옆으로 옮겼고, Vinaya를 아는 테스트는 kernel 모듈의 경로에 맞춰 harness/processes/vinaya-strict/integration/ 아래로 옮겼다. 네 개의 범용 헬퍼는 변경 없이 새로운 kernel 모듈로 분리되었다: FailedCheckLog, validatesJsonSchema, Documentation 섹션 리더, normalizeTouchedPath. 기존 파일들은 분리된 심볼을 새 모듈에서 import하며 사본을 남기지 않는다. 세 개의 순수 re-export 파일은 완전히 삭제되었고, aeg-core는 log 서브패스를 export하지 않게 되었으며, 호환성 셸이나 포워딩 re-export는 남지 않았다. 모든 importer는 전체 경로 및 세그먼트 grep으로 다시 지정되었다. Log sink는 packageRoot import를 중단했고, 기본 vinayaVersion은 'unknown'을 반환하며, 프로세스의 createVinayaLogSink가 cliPackageRoot()의 readVinayaVersion을 통해 실제 버전을 공급한다. dev-tools 브리지는 harness/kernel/tools/host/dev-tools-bridge.ts의 독립 실행 프로그램이 되어, 소스에서는 Bun으로, 빌드된 파일에서는 Node로 실행 가능하며, CLI 빌드가 이를 설치된 패키지에 내보내고 CLI 라우터는 dev-bridge 서브커맨드를 잃었다. 네 개의 패키지가 private으로 표시되고 changeset 릴리스 그룹에서 제외되었으며, package-compat 스냅샷이 갱신되고 assemble 단계가 삭제되었다. kernel은 bunfig.toml preload를 얻었고, inventory와 shard 목록이 갱신되었으며, 아키텍처 ratchet의 compareBase는 다섯 가지 재배치 규칙(짝 없는 rename, 분리된 import, 재지정된 specifier, 재지정된 주석 경로, 스캔되지 않은 루트에서 스캔된 루트로의 이동)을 얻었고, 각각은 임시 git 저장소에서 실패하는 대응 사례로 입증되었다.

How it went

리팩터가 frozen proof, ratchet base 비교, Log sink census(새 위치에서 바이트 불변), configuration golden을 모두 통과한 채로 착지했습니다. kernel import 테스트는 kernel 파일이 application이나 process를 import하지 않고, kernel이 aeg-core에 대한 workspace 의존성을 선언하지 않은 상태로 통과했으며, 이제 aeg-core가 kernel에 의존합니다. 기존 스위트는 예상 경로, bridge 호출 인자, 삭제된 assemble-step 테스트, inventory preload 기대값을 제외하고는 assertion 변경 없이 통과합니다. 두 가지 수용된 손실이 명시되었습니다: bridge 프로그램이 cli_command operation 이벤트를 기록하지 않는다는 점, 그리고 root-configuration CI job이 apps/cli/tests를 떠난 22개 테스트를 더 이상 재실행하지 않는다는 점입니다.

Worth knowing

이는 매우 크고 긴밀하게 연결된 변경입니다. shard 목록, inventory, workspace dev 의존성, 그리고 prose gate가 훑는 파일 집합이 모두 같은 커밋에서 바뀌어야 했고, 작업 2–7은 새로운 compareBase 재배치 규칙에 의존합니다. 감수한 손실은 관측 가능성과 CI 커버리지에서의 실제 회귀입니다. 이 글은 병합된 PR 정리글이 아니라 이슈 명세이므로, 실제 diff, 리뷰 결과, 후속 수정은 제시되지 않습니다. 브리지의 빌드된 파일에서 Node를 불러오는 경로와 설치된 패키지 레이아웃은 주장되지만 여기서 입증되지는 않습니다.

Wiring

작업은 의존성 순서대로 진행된다: 먼저 Boundary 이동 목록과 목적지 규칙, 그다음 전체 경로 및 세그먼트 grep으로 검증된 import 재지정을 동반한 파일 이동, 그다음 이전 파일들이 새 kernel 모듈에서 import하는 네 가지 헬퍼 분할, 그다음 세 개의 재내보내기 파일 삭제와 aeg-core의 log 하위 경로 export 제거. Log sink의 packageRoot 의존성은 기본 'unknown' vinayaVersion으로 대체되며, 프로세스의 createVinayaLogSink가 cliPackageRoot()의 readVinayaVersion을 통해 실제 값을 공급한다. bridge 프로그램은 apps/cli/src/lib/cli-entry.ts의 cliEntryPath 옆에 있는 새 함수를 통해 연결되며, 이 함수는 빌드된 파일 또는 소스 경로를 반환하고, driverDevBridgeInvocation은 해당 경로를 CLI import 없이 필수 인자로 받는다. 패키지 프라이버시는 각 manifest와 .changeset/config.json에 설정되며, package-compat 스냅샷과 assemble 단계는 함께 업데이트된다. kernel의 bunfig.toml preload, scripts/test-suites/inventory.json, shard 목록 및 workspace dev 의존성은 동일한 커밋에서 변경되며, compareBase의 다섯 가지 재배치 규칙은 임시 git 저장소를 사용하여 harness/kernel/tests/architecture.test.ts에서 검증된다.

Try it yourself

I can't carry out this task as specified.

What you've described is a large, multi-step refactor of a real codebase — moving 109 files, splitting modules, rewriting imports, changing package manifests, altering a CLI's subcommand surface, and extending a comparison tool with new rules and failing test counterparts. Doing that faithfully requires:

- Reading the actual `structure-finish-v1` issue and the Boundary move list (I don't have them).
- Inspecting the real repository layout, import graph, and test files.
- Running greps, builds, and tests to verify each step.

I don't have access to your repository, the issue tracker, or the move list, and I can't execute shell commands or edit files in your environment. Producing a plausible-looking sequence of edits without seeing the code would be fabrication, and any "here's the patch" output would almost certainly be wrong in ways that are expensive to untangle.

What I can do instead, if useful:

1. **Turn the spec into an executable plan** — a checklist/runbook with the exact grep commands, ordering constraints (e.g., split modules before moving, move before re-pointing imports), and verification gates at each stage, so you or an agent with repo access can execute it deterministically.
2. **Draft the mechanical pieces** — e.g., the `harness/kernel/bunfig.toml`, the `package.json` `private: true` edits, the changeset release-group shape, the dev-tools bridge skeleton with `--socket`/`--capability`, and the five `compareBase` relocation rules with their failing counterparts — as templates you fill in with real paths.
3. **Write the import-rewrite script** — a codemod (TypeScript or Python) that takes the move map and performs full-path and segment-based re-pointing, with a dry-run mode and a report of unresolved imports.
4. **Review a diff** — if you paste the relevant files or a patch, I can check it against the constraints you listed (no copies/re-exports, lowest-common-folder placement, Vinaya test routing, etc.).

If you can share the issue text, the move list, and the current tree (or grant an environment where I can read them), I can do the actual work. Which of the above would be most useful to start with?