sb-codex-tool 0.1.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.ko.md ADDED
@@ -0,0 +1,304 @@
1
+ # sb-codex-tool
2
+
3
+ `sb-codex-tool`은 일반 소프트웨어 프로젝트를 위한 가벼운 `Codex`
4
+ workflow/runtime scaffold입니다.
5
+
6
+ 프로젝트 상태, hot path 가이드, fresh-agent verification, 사람이 읽는
7
+ 작업일지를 한눈에 확인 가능한 구조로 유지하면서도 코드베이스 전체를
8
+ 덮어쓰지 않도록 설계되어 있습니다.
9
+
10
+ 영문 README: [README.md](./README.md)
11
+ 처음 사용자 가이드: [docs/menu/getting-started.md](https://github.com/SBCHOE-AI/sb-codex-tool/blob/main/docs/menu/getting-started.md)
12
+
13
+ ## 왜 필요한가
14
+
15
+ `sb-codex-tool`은 agent 기반 작업을 더 엄격하게 운영하고 싶지만, 무거운
16
+ 플랫폼을 도입하고 싶지 않은 프로젝트를 위해 만들어졌습니다.
17
+
18
+ 이 도구가 해결하려는 핵심 문제는 다음과 같습니다.
19
+
20
+ - 현재 작업 상태를 fresh agent도 바로 이해할 수 있게 유지하기
21
+ - non-trivial 작업을 `plan -> execute -> refactor -> verify`로 강제하기
22
+ - 최종 verification을 항상 fresh agent가 수행하게 만들기
23
+ - agent용 상태와 사람용 작업일지를 분리해 두기
24
+ - onboarding과 verification을 짧은 hot path로 고정하기
25
+
26
+ 목표는 Codex를 대체하는 것이 아니라, 일반적인 repository 안에서 Codex
27
+ 작업을 더 반복 가능하고 검증 가능하게 만드는 것입니다.
28
+
29
+ ## 핵심 원칙
30
+
31
+ - 최종 closure에는 fresh verification이 필수입니다.
32
+ - 상태는 세션이 바뀌어도 유지되어야 합니다.
33
+ - main agent의 사용자 진행 보고는 짧고 한국어로 유지합니다.
34
+ - subagent는 범위를 좁게 잡고, 완료 후 clear 또는 replace합니다.
35
+ - 코드는 재사용 가능하고, 짧고, 읽기 쉽고, 복잡하지 않게 유지합니다.
36
+ - 사람용 작업 로그와 agent continuity state는 분리합니다.
37
+
38
+ ## 요구 사항
39
+
40
+ - Node.js 25 이상
41
+ - Codex가 working tree를 읽고 쓸 수 있는 프로젝트
42
+ - 기본 launch wrapper를 쓸 경우 `codex` 바이너리
43
+ - 명시적 상태, handoff, verification artifact가 필요한 작업 방식
44
+
45
+ ## 설치
46
+
47
+ npm publish 이후 일회성으로 바로 실행할 때:
48
+
49
+ ```bash
50
+ npx sb-codex-tool@latest setup
51
+ ```
52
+
53
+ npm publish 이후 로컬에 설치해서 사용할 때:
54
+
55
+ ```bash
56
+ npm install --save-dev sb-codex-tool
57
+ npm exec sb-codex-tool -- setup
58
+ ```
59
+
60
+ public GitHub repository에서 로컬에 설치해서 사용할 때:
61
+
62
+ ```bash
63
+ npm install --save-dev git+https://github.com/SBCHOE-AI/sb-codex-tool.git
64
+ npm exec sb-codex-tool -- setup
65
+ ```
66
+
67
+ ## 빠른 시작
68
+
69
+ repository에 scaffold를 초기화합니다.
70
+
71
+ ```bash
72
+ sb-codex-tool setup
73
+ ```
74
+
75
+ 현재 scaffold와 운영 상태를 점검합니다.
76
+
77
+ ```bash
78
+ sb-codex-tool doctor
79
+ sb-codex-tool status
80
+ ```
81
+
82
+ bounded work cycle을 시작합니다.
83
+
84
+ ```bash
85
+ sb-codex-tool begin add-status-panel "Add Status Panel"
86
+ ```
87
+
88
+ 현재 cycle을 fresh verification 준비 상태로 올립니다.
89
+
90
+ ```bash
91
+ sb-codex-tool prepare-verify
92
+ ```
93
+
94
+ fresh verification agent가 verdict를 남긴 뒤 cycle을 닫습니다.
95
+
96
+ ```bash
97
+ sb-codex-tool close
98
+ ```
99
+
100
+ ## `setup`이 만드는 것
101
+
102
+ `setup`은 `.sb-codex-tool/` 상태 루트와 repo 운영 문서를 만듭니다.
103
+
104
+ ```text
105
+ .sb-codex-tool/
106
+ guides/
107
+ handoffs/
108
+ ignore/
109
+ index/
110
+ logs/work-journal/
111
+ plans/
112
+ reviews/
113
+ runs/
114
+ summaries/
115
+ workflows/
116
+ AGENTS.md
117
+ .ignore
118
+ .rgignore
119
+ ```
120
+
121
+ 이 구조는 bounded work cycle, hot-path onboarding, fresh verification,
122
+ 사람이 읽는 work journal을 운영하는 데 필요한 최소 세트입니다.
123
+
124
+ ## 명령어
125
+
126
+ | 명령 | 목적 |
127
+ | --- | --- |
128
+ | `sb-codex-tool setup` | scaffold, workflow 자산, 가이드, ignore 파일을 생성합니다. |
129
+ | `sb-codex-tool doctor` | scaffold 무결성, 현재 cycle 준비도, semantic coherence를 검사합니다. |
130
+ | `sb-codex-tool status` | 현재 stage, next action, hot path, 최신 run, semantic issue를 보여줍니다. |
131
+ | `sb-codex-tool begin <slug> [title words]` | plan/summary/handoff/review artifact를 갖는 새 cycle을 엽니다. |
132
+ | `sb-codex-tool prepare-verify` | 현재 cycle을 verify-ready 상태로 옮기고 handoff를 다시 씁니다. |
133
+ | `sb-codex-tool close` | fresh verification verdict를 읽어 cycle을 최종 종료합니다. |
134
+ | `sb-codex-tool assign <agent-name> <slug> [title words]` | subagent용 bounded assignment guide를 생성합니다. |
135
+ | `sb-codex-tool complete-assignment <agent-name> <close\|clear\|replace> ...` | 완료된 subagent assignment의 lifecycle 처리를 기록합니다. |
136
+ | `sb-codex-tool review-consistency <agent-name> [title words]` | active cycle에 대한 consistency review artifact를 생성합니다. |
137
+ | `sb-codex-tool [codex args]` | 명시적 명령이 없으면 wrapper를 통해 Codex를 실행합니다. |
138
+
139
+ ## 워크플로 모델
140
+
141
+ `sb-codex-tool`은 다섯 단계 루프를 사용합니다.
142
+
143
+ 1. `clarify`
144
+ 2. `plan`
145
+ 3. `execute`
146
+ 4. `refactor`
147
+ 5. `verify`
148
+
149
+ 최종 verification은 항상 fresh agent가 수행합니다. non-trivial 작업은
150
+ 일반적으로 `prepare-verify`를 거친 뒤 fresh verification을 수행하고, 마지막에
151
+ `close`로 닫습니다.
152
+
153
+ ### 일반적인 cycle
154
+
155
+ 1. `begin`으로 새 cycle을 엽니다.
156
+ 2. approved plan과 scope guide를 실제 작업 내용으로 채웁니다.
157
+ 3. 구현을 진행하고 execution summary를 갱신합니다.
158
+ 4. 단순성, 재사용성, 가독성을 기준으로 refactor합니다.
159
+ 5. `prepare-verify`를 실행해 handoff, state, verification 입력을 정렬합니다.
160
+ 6. fresh verification agent가 contract, hot path, 코드, 검증 명령을 독립적으로 확인합니다.
161
+ 7. fresh verifier가 verdict를 남긴 뒤 `close`를 실행합니다.
162
+
163
+ ## 상태 구조
164
+
165
+ `setup`은 아래와 같은 `.sb-codex-tool/` 상태 루트를 만듭니다.
166
+
167
+ - `project.md`
168
+ - `state.md`
169
+ - `plans/`
170
+ - `runs/`
171
+ - `summaries/`
172
+ - `handoffs/`
173
+ - `guides/`
174
+ - `reviews/`
175
+ - `logs/work-journal/`
176
+
177
+ hot-path onboarding은 다음 순서로 시작합니다.
178
+
179
+ 1. `.sb-codex-tool/project.md`
180
+ 2. `.sb-codex-tool/state.md`
181
+ 3. `.sb-codex-tool/guides/read-this-first.md`
182
+ 4. `.sb-codex-tool/guides/code-consistency.md`
183
+
184
+ ### 디렉터리별 책임
185
+
186
+ - `project.md`: 장기적인 프로젝트 설명과 아키텍처 진입점
187
+ - `state.md`: 현재 stage, next action, active reference, agent map
188
+ - `plans/`: approved plan과 draft plan
189
+ - `runs/`: lifecycle run과 launch metadata
190
+ - `summaries/`: execution summary와 verification summary
191
+ - `handoffs/`: 다음 agent가 바로 이어받기 위한 guidance
192
+ - `guides/`: code consistency, read-this-first, task-specific guide
193
+ - `reviews/`: consistency review와 fresh verification artifact
194
+ - `logs/work-journal/`: 사람이 읽는 일일 작업 기록
195
+
196
+ ## Agent 모델
197
+
198
+ ### Main Agent
199
+
200
+ - orchestration을 소유합니다.
201
+ - 사용자 진행 상황을 한국어로 보고합니다.
202
+ - subagent에 bounded task를 배정합니다.
203
+ - 최종 통합과 closure를 담당합니다.
204
+
205
+ ### Subagent
206
+
207
+ - 하나의 좁은 task 범위만 맡아야 합니다.
208
+ - unrelated context를 계속 쌓지 않아야 합니다.
209
+ - 완료 후 clear 또는 replace가 기본값입니다.
210
+
211
+ ### Verification Agent
212
+
213
+ - 항상 fresh agent여야 합니다.
214
+ - 실행한 agent와 같으면 안 됩니다.
215
+ - 문서화된 hot path와 verification contract를 기준으로 판정합니다.
216
+
217
+ ### Consistency Agent
218
+
219
+ - 구조, naming, module boundary, 재사용성/가독성 drift를 점검합니다.
220
+ - `code-consistency.md`를 기준 문서로 사용합니다.
221
+
222
+ ## Verification 모델
223
+
224
+ `verify`는 단순히 테스트 통과를 의미하지 않습니다.
225
+
226
+ fresh verification에서는 최소한 다음을 확인해야 합니다.
227
+
228
+ - plan vs actual
229
+ - next-agent guidance 품질
230
+ - readability와 code consistency 정렬 상태
231
+ - active artifact completeness
232
+ - state와 latest run metadata 사이의 semantic coherence
233
+
234
+ 이 조건이 맞지 않으면 closure를 하면 안 됩니다.
235
+
236
+ ## Work Journal
237
+
238
+ 검증이 끝난 뒤 main agent는 사람이 읽는 작업일지를 다음 위치에 남깁니다.
239
+
240
+ ```text
241
+ .sb-codex-tool/logs/work-journal/YYYY-MM-DD.md
242
+ ```
243
+
244
+ 이 문서는 agent continuity state와 의도적으로 분리되어 있습니다. 내부 run
245
+ artifact를 읽지 않고도 “오늘 무엇을 했는지”를 사람이 빠르게 확인할 수 있게
246
+ 만드는 용도입니다.
247
+
248
+ ## Git 및 Repository Context
249
+
250
+ `sb-codex-tool`은 git을 destructive automation 표면이 아니라 context 지원
251
+ 도구로 사용합니다.
252
+
253
+ 현재 활용 범위는 다음과 같습니다.
254
+
255
+ - branch와 dirty state 확인
256
+ - changed-file scope를 run artifact에 기록
257
+ - launch/closure evidence와 git context 연결
258
+
259
+ core에서는 의도적으로 destructive git automation을 하지 않습니다.
260
+
261
+ ## 패키징 점검
262
+
263
+ 배포 전에 다음 명령을 실행합니다.
264
+
265
+ ```bash
266
+ npm run test
267
+ npm run pack:check
268
+ ```
269
+
270
+ `pack:check`는 tarball이 로컬 상태 파일, tests, 내부 연구 문서를 싣지 않고,
271
+ CLI runtime surface 중심으로 유지되는지 확인합니다. 다만 `README.md`,
272
+ `README.ko.md` 같은 루트 README 문서는 npm 동작에 따라 함께 포함될 수
273
+ 있습니다.
274
+
275
+ 좀 더 큰 로컬 release check가 필요하면:
276
+
277
+ ```bash
278
+ npm run release:check
279
+ ```
280
+
281
+ ## 개발 메모
282
+
283
+ - 현재 패키지는 Node의 `--experimental-strip-types`를 통해 TypeScript를 직접 실행합니다.
284
+ - 배포 surface는 `package.json#files`로 제한합니다.
285
+ - published tarball은 runtime 파일과 npm이 자동 포함하는 루트 README 문서
286
+ (`README.md`, `README.ko.md`) 중심으로 유지됩니다.
287
+ - 내부 `.sb-codex-tool/` 상태는 repository 안에서는 유용하지만 package payload에는 포함되지 않습니다.
288
+
289
+ ## 현재 상태
290
+
291
+ 현재 repository에는 다음 기능이 포함되어 있습니다.
292
+
293
+ - scaffold 생성 및 검증
294
+ - bounded work-cycle automation
295
+ - launch wrapper hardening
296
+ - assignment lifecycle handling
297
+ - consistency review flow
298
+ - `doctor`와 `status`의 semantic coherence 검사
299
+ - npm distribution readiness checks
300
+
301
+ ## 라이선스
302
+
303
+ 현재 package metadata는 `UNLICENSED`로 설정되어 있습니다. 공개 오픈소스로
304
+ 배포할 경우에는 원하는 배포 모델에 맞게 조정해야 합니다.
package/README.md ADDED
@@ -0,0 +1,309 @@
1
+ # sb-codex-tool
2
+
3
+ `sb-codex-tool` is a lightweight Codex workflow and runtime scaffold for
4
+ general software projects.
5
+
6
+ It keeps project state, hot-path guidance, fresh-agent verification, and
7
+ human-readable work journals in one inspectable layout without taking over the
8
+ whole codebase.
9
+
10
+ Korean README: [README.ko.md](https://github.com/SBCHOE-AI/sb-codex-tool/blob/main/README.ko.md)
11
+ First-time Codex guide: [docs/menu/getting-started.md](https://github.com/SBCHOE-AI/sb-codex-tool/blob/main/docs/menu/getting-started.md)
12
+
13
+ ## Why It Exists
14
+
15
+ `sb-codex-tool` is designed for projects that want stronger agent discipline
16
+ without introducing a heavy platform.
17
+
18
+ The tool focuses on a few practical problems:
19
+
20
+ - keeping the current task state visible to fresh agents
21
+ - forcing non-trivial work through `plan -> execute -> refactor -> verify`
22
+ - making final verification fresh-agent-only
23
+ - preserving a human-readable work journal alongside agent-focused state
24
+ - keeping onboarding and verification on a compact hot path
25
+
26
+ It is intentionally small. The goal is not to replace Codex, but to make Codex
27
+ work more repeatable inside a normal repository.
28
+
29
+ ## Core Principles
30
+
31
+ - Fresh verification is mandatory for final closure.
32
+ - State should survive session boundaries.
33
+ - Main-agent progress updates should be concise and in Korean.
34
+ - Subagents should stay bounded and disposable.
35
+ - Code should stay reusable, short, readable, and low-complexity.
36
+ - Human work logs and agent continuity state should remain separate.
37
+
38
+ ## Requirements
39
+
40
+ - Node.js 25 or newer
41
+ - A project where Codex can read and write the working tree
42
+ - A `codex` binary available when using the default launch wrapper
43
+ - A workflow that benefits from explicit state, handoff, and verification
44
+ artifacts
45
+
46
+ ## Install
47
+
48
+ One-off from npm after publish:
49
+
50
+ ```bash
51
+ npx sb-codex-tool@latest setup
52
+ ```
53
+
54
+ Install locally from npm after publish:
55
+
56
+ ```bash
57
+ npm install --save-dev sb-codex-tool
58
+ npm exec sb-codex-tool -- setup
59
+ ```
60
+
61
+ Install locally from the public GitHub repository:
62
+
63
+ ```bash
64
+ npm install --save-dev git+https://github.com/SBCHOE-AI/sb-codex-tool.git
65
+ npm exec sb-codex-tool -- setup
66
+ ```
67
+
68
+ ## Quick Start
69
+
70
+ Initialize the scaffold in a repository:
71
+
72
+ ```bash
73
+ sb-codex-tool setup
74
+ ```
75
+
76
+ Inspect the scaffold and operational state:
77
+
78
+ ```bash
79
+ sb-codex-tool doctor
80
+ sb-codex-tool status
81
+ ```
82
+
83
+ Start a bounded work cycle:
84
+
85
+ ```bash
86
+ sb-codex-tool begin add-status-panel "Add Status Panel"
87
+ ```
88
+
89
+ Prepare the current cycle for fresh verification:
90
+
91
+ ```bash
92
+ sb-codex-tool prepare-verify
93
+ ```
94
+
95
+ Close the cycle after a fresh verification agent records a verdict:
96
+
97
+ ```bash
98
+ sb-codex-tool close
99
+ ```
100
+
101
+ ## What `setup` Creates
102
+
103
+ `setup` scaffolds a `.sb-codex-tool/` state root and repo guidance:
104
+
105
+ ```text
106
+ .sb-codex-tool/
107
+ guides/
108
+ handoffs/
109
+ ignore/
110
+ index/
111
+ logs/work-journal/
112
+ plans/
113
+ reviews/
114
+ runs/
115
+ summaries/
116
+ workflows/
117
+ AGENTS.md
118
+ .ignore
119
+ .rgignore
120
+ ```
121
+
122
+ This is the minimum structure needed for bounded work cycles, hot-path
123
+ onboarding, fresh verification, and human-readable work journaling.
124
+
125
+ ## Commands
126
+
127
+ | Command | Purpose |
128
+ | --- | --- |
129
+ | `sb-codex-tool setup` | Create the scaffold, workflow assets, guides, and ignore files. |
130
+ | `sb-codex-tool doctor` | Validate scaffold integrity, current-cycle readiness, and semantic coherence. |
131
+ | `sb-codex-tool status` | Show the current stage, next action, hot path, latest run details, and semantic issues. |
132
+ | `sb-codex-tool begin <slug> [title words]` | Open a new bounded work cycle with plan/summary/handoff/review artifacts. |
133
+ | `sb-codex-tool prepare-verify` | Move the current cycle into verify-ready state and rewrite the handoff. |
134
+ | `sb-codex-tool close` | Finalize the current cycle from the recorded fresh verification verdict. |
135
+ | `sb-codex-tool assign <agent-name> <slug> [title words]` | Create a bounded assignment guide for a subagent. |
136
+ | `sb-codex-tool complete-assignment <agent-name> <close\|clear\|replace> ...` | Record lifecycle handling for a completed subagent assignment. |
137
+ | `sb-codex-tool review-consistency <agent-name> [title words]` | Write a bounded consistency review artifact for the active cycle. |
138
+ | `sb-codex-tool [codex args]` | Launch Codex through the wrapper when no explicit command is given. |
139
+
140
+ ## Workflow Model
141
+
142
+ `sb-codex-tool` uses a five-stage loop:
143
+
144
+ 1. `clarify`
145
+ 2. `plan`
146
+ 3. `execute`
147
+ 4. `refactor`
148
+ 5. `verify`
149
+
150
+ Final verification is always fresh-agent-only. Non-trivial work is expected to
151
+ end with `prepare-verify` and then a fresh verification pass before `close`.
152
+
153
+ ### Typical Cycle
154
+
155
+ 1. Run `begin` to open a new cycle.
156
+ 2. Fill the approved plan and scope guide with real work.
157
+ 3. Implement the change and update the execution summary.
158
+ 4. Refactor for simplicity, reuse, and readability.
159
+ 5. Run `prepare-verify` to align handoff, state, and verification inputs.
160
+ 6. Have a fresh verification agent inspect the contracts, hot path, code, and
161
+ checks.
162
+ 7. Run `close` after the fresh verifier records a verdict.
163
+
164
+ ## State Layout
165
+
166
+ `setup` creates a `.sb-codex-tool/` state root that includes:
167
+
168
+ - `project.md`
169
+ - `state.md`
170
+ - `plans/`
171
+ - `runs/`
172
+ - `summaries/`
173
+ - `handoffs/`
174
+ - `guides/`
175
+ - `reviews/`
176
+ - `logs/work-journal/`
177
+
178
+ Hot-path onboarding starts with:
179
+
180
+ 1. `.sb-codex-tool/project.md`
181
+ 2. `.sb-codex-tool/state.md`
182
+ 3. `.sb-codex-tool/guides/read-this-first.md`
183
+ 4. `.sb-codex-tool/guides/code-consistency.md`
184
+
185
+ ### Directory Responsibilities
186
+
187
+ - `project.md`: durable project truth and architectural entrypoints
188
+ - `state.md`: current stage, next action, active references, and agent map
189
+ - `plans/`: approved and draft work-cycle plans
190
+ - `runs/`: lifecycle and launch metadata
191
+ - `summaries/`: execution and verification summaries
192
+ - `handoffs/`: next-agent guidance for bounded verification or continuation
193
+ - `guides/`: code consistency, read-first, and task-specific guidance
194
+ - `reviews/`: consistency and fresh-verification artifacts
195
+ - `logs/work-journal/`: human-readable daily work logs
196
+
197
+ ## Agent Model
198
+
199
+ ### Main Agent
200
+
201
+ - Owns orchestration
202
+ - Reports progress to the user in Korean
203
+ - Assigns bounded work to subagents
204
+ - Integrates and closes work
205
+
206
+ ### Subagents
207
+
208
+ - Should stay bounded to one narrow task
209
+ - Should not accumulate unrelated context
210
+ - Should be cleared or replaced after completion
211
+
212
+ ### Verification Agent
213
+
214
+ - Must be fresh
215
+ - Must not be the same agent that executed the work
216
+ - Uses the documented hot path and verification contract
217
+
218
+ ### Consistency Agent
219
+
220
+ - Reviews structure, naming, module boundaries, and reuse/readability drift
221
+ - Uses `code-consistency.md` as the baseline
222
+
223
+ ## Verification Model
224
+
225
+ `verify` is not just “tests passed”.
226
+
227
+ Fresh verification is expected to confirm:
228
+
229
+ - plan vs actual
230
+ - next-agent guidance quality
231
+ - readability and code-consistency alignment
232
+ - active artifact completeness
233
+ - semantic coherence between state and latest run metadata
234
+
235
+ If those conditions are not met, closure should not happen.
236
+
237
+ ## Work Journal
238
+
239
+ After verified completion, the main agent writes a human-readable work log
240
+ entry in:
241
+
242
+ ```text
243
+ .sb-codex-tool/logs/work-journal/YYYY-MM-DD.md
244
+ ```
245
+
246
+ This journal is intentionally separate from agent continuity state. It is for
247
+ people who want to know what changed today without reading internal run
248
+ artifacts.
249
+
250
+ ## Git and Repository Context
251
+
252
+ `sb-codex-tool` uses git as context support, not as a destructive automation
253
+ surface.
254
+
255
+ Current usage includes:
256
+
257
+ - branch and dirty-state inspection when available
258
+ - changed-file context capture in run artifacts
259
+ - launch and closure evidence linking
260
+
261
+ It deliberately avoids destructive git automation in the core.
262
+
263
+ ## Packaging Checks
264
+
265
+ Use these commands before publishing or sharing a tarball:
266
+
267
+ ```bash
268
+ npm run test
269
+ npm run pack:check
270
+ ```
271
+
272
+ `pack:check` verifies the published tarball surface stays focused on the CLI
273
+ runtime rather than shipping local state, tests, or internal research docs.
274
+ Root README documents such as `README.md` and `README.ko.md` may still be
275
+ included by npm as repository-facing documentation.
276
+
277
+ For a fuller local release check:
278
+
279
+ ```bash
280
+ npm run release:check
281
+ ```
282
+
283
+ ## Development Notes
284
+
285
+ - The package currently runs TypeScript directly through Node's
286
+ `--experimental-strip-types` support.
287
+ - The distribution surface is controlled with `package.json#files`.
288
+ - The published tarball is intentionally limited to runtime files plus root
289
+ README documents that npm auto-includes, such as `README.md` and
290
+ `README.ko.md`.
291
+ - Internal `.sb-codex-tool/` state is useful inside the repository, but is not
292
+ part of the package payload.
293
+
294
+ ## Current Status
295
+
296
+ The repository currently includes:
297
+
298
+ - scaffold creation and validation
299
+ - bounded work-cycle automation
300
+ - launch wrapper hardening
301
+ - assignment lifecycle handling
302
+ - consistency review flow
303
+ - semantic coherence checks for `doctor` and `status`
304
+ - npm distribution readiness checks
305
+
306
+ ## License
307
+
308
+ The current package metadata is marked `UNLICENSED`. Adjust that before public
309
+ open-source publication if you choose a different distribution model.
@@ -0,0 +1,18 @@
1
+ #!/usr/bin/env node
2
+ import { spawnSync } from 'node:child_process';
3
+ import path from 'node:path';
4
+ import { fileURLToPath } from 'node:url';
5
+
6
+ const here = path.dirname(fileURLToPath(import.meta.url));
7
+ const cliPath = path.resolve(here, '../dist/cli.js');
8
+ const result = spawnSync(
9
+ process.execPath,
10
+ [cliPath, ...process.argv.slice(2)],
11
+ { stdio: 'inherit' },
12
+ );
13
+
14
+ if (result.error) {
15
+ throw result.error;
16
+ }
17
+
18
+ process.exit(result.status ?? 1);