From 407be35b41e6327218303b63a426ab1f57cd456a Mon Sep 17 00:00:00 2001
From: phroi <90913182+phroi@users.noreply.github.com>
Date: Sun, 22 Feb 2026 14:34:29 +0000
Subject: [PATCH 1/5] docs(01): capture phase 1 context and state tracking

Record architectural decisions from phase 1 context session:
TransactionLike convention, getHeader/HeaderKey removal, headerDeps
management approach. Update STATE.md with session progress.
---
 .planning/STATE.md                            |  23 ++--
 .../01-CONTEXT.md                             | 100 ++++++++++++++++++
 2 files changed, 113 insertions(+), 10 deletions(-)
 create mode 100644 .planning/phases/01-ickb-utils-smarttransaction-removal/01-CONTEXT.md

diff --git a/.planning/STATE.md b/.planning/STATE.md
index 218ac61..caed793 100644
--- a/.planning/STATE.md
+++ b/.planning/STATE.md
@@ -5,14 +5,14 @@
 See: .planning/PROJECT.md (updated 2026-02-20)
 
 **Core value:** Clean, CCC-aligned library packages published to npm that frontends can depend on to interact with iCKB contracts -- no Lumos, no abandoned abstractions, no duplicated functionality with CCC.
-**Current focus:** Phase 1: @ickb/utils SmartTransaction Removal
+**Current focus:** Phase 1: SmartTransaction Removal (feature-slice)
 
 ## Current Position
 
-Phase: 1 of 7 (@ickb/utils SmartTransaction Removal)
+Phase: 1 of 7 (SmartTransaction Removal — feature-slice)
 Plan: 0 of 3 in current phase
-Status: Ready to plan
-Last activity: 2026-02-21 -- Roadmap created
+Status: Context gathered, ready to plan
+Last activity: 2026-02-22 -- Phase 1 context gathered
 
 Progress: [░░░░░░░░░░] 0%
 
@@ -42,9 +42,12 @@ Progress: [░░░░░░░░░░] 0%
 Decisions are logged in PROJECT.md Key Decisions table.
 Recent decisions affecting current work:
 
-- [Roadmap]: Bottom-up refactor order follows package dependency graph: utils -> dao+order -> core -> sdk
-- [Roadmap]: UDT investigation (Phase 3) is a design phase that produces a decision document before core implementation (Phase 5)
-- [Roadmap]: SMTX-01 (all managers accept ccc.Transaction) is verified at Phase 5 completion, after utils managers removed (Phase 1), dao+order managers updated (Phase 4), and core managers updated (Phase 5)
+- [Roadmap]: Phase 1 uses feature-slice approach — each removal chased across all packages, build stays green after every step. SMTX-01 (all signatures to TransactionLike) completed in Phase 1, not Phase 5.
+- [Roadmap]: UDT investigation (Phase 3) is a design phase that produces a decision document; its outcome determines UdtHandler/UdtManager replacement pattern used in Phases 4-5
+- [Roadmap]: Phases 4-5 reduced in scope: Phase 4 focuses on deprecated API replacement + UDT pattern finalization in dao/order; Phase 5 focuses on IckbUdt implementation + conservation law in core
+- [Phase 1 Context]: DAO 64-output limit check contributed to CCC core via ccc-dev/, CCC PR submitted during Phase 1
+- [Phase 1 Context]: getHeader()/HeaderKey removed entirely — inline CCC client calls at read-only call sites; addHeaders() call sites in DaoManager/LogicManager push to tx.headerDeps directly
+- [Phase 1 Context]: Script comparison must always use full Script.eq(), never just codeHash comparison
 
 ### Pending Todos
 
@@ -57,6 +60,6 @@ None yet.
 
 ## Session Continuity
 
-Last session: 2026-02-21
-Stopped at: Roadmap created, ready for Phase 1 planning
-Resume file: None
+Last session: 2026-02-22
+Stopped at: Phase 1 context gathered
+Resume file: .planning/phases/01-ickb-utils-smarttransaction-removal/01-CONTEXT.md
diff --git a/.planning/phases/01-ickb-utils-smarttransaction-removal/01-CONTEXT.md b/.planning/phases/01-ickb-utils-smarttransaction-removal/01-CONTEXT.md
new file mode 100644
index 0000000..d678251
--- /dev/null
+++ b/.planning/phases/01-ickb-utils-smarttransaction-removal/01-CONTEXT.md
@@ -0,0 +1,100 @@
+# Phase 1: SmartTransaction Removal (feature-slice) - Context
+
+**Gathered:** 2026-02-22
+**Status:** Ready for planning
+
+<domain>
+## Phase Boundary
+
+Delete SmartTransaction class and its infrastructure across all packages; contribute 64-output DAO limit check to CCC core; remove getHeader()/HeaderKey and inline CCC client calls; migrate all method signatures to ccc.TransactionLike. Using a **feature-slice approach**: each removal is chased across ALL packages so the build stays green at every step.
+
+</domain>
+
+<decisions>
+## Implementation Decisions
+
+### CCC DAO Contribution (via ccc-dev/)
+- Build the 64-output NervosDAO limit check **in CCC core**, not in @ickb/utils
+- Develop in `ccc-dev/ccc/`, record pins, use immediately via workspace override while waiting for upstream merge
+- **Submit the upstream CCC PR during Phase 1 execution**
+- CCC PR includes three components:
+  1. **`completeFee()` safety net** — async check using `client.getKnownScript(KnownScript.NervosDao)` with full `Script.eq()` comparison
+  2. **Standalone utility function** — `assertDaoOutputLimit(tx, client)` that auto-resolves unresolved inputs (populating `CellInput.cellOutput` as a side effect) and checks both inputs and outputs
+  3. **`ErrorNervosDaoOutputLimit` error class** in `transactionErrors.ts` with metadata fields (count) and hardcoded limit of 64
+- The check logic: if `outputs.length > 64` AND any input or output has DAO type script, throw error
+- **PR description should mention** the possibility of adding the check to `addOutput()` as a future enhancement, inviting maintainer feedback
+- All 6+ scattered DAO checks across dao/core/utils packages are replaced with calls to the new CCC utility **in Phase 1**
+
+### getHeader() Removal
+- **Remove `getHeader()` function and `HeaderKey` type entirely** from @ickb/utils
+- Inline CCC client calls at each of the 8+ call sites across dao/core/sdk:
+  - `txHash` lookups → `(await client.getTransactionWithHeader(hash))?.header` with null check/throw
+  - `number` lookups → `await client.getHeaderByNumber(n)` with null check/throw
+- SmartTransaction's redundant `Map<hexString, Header>` cache is deleted — CCC's built-in `ClientCacheMemory` LRU (128 blocks) handles caching
+- **`addHeaders()` replacement needed** — `SmartTransaction.addHeaders()` is used by DaoManager (`requestWithdrawal`, `withdraw`) and LogicManager (`completeDeposit`) to push header hashes into `tx.headerDeps` with dedup. With SmartTransaction gone, these 3 call sites need to push to `tx.headerDeps` directly. Note: `SmartTransaction.getHeader()` (instance method) only validated that headers were already in headerDeps — it did not populate them. The standalone `getHeader()` function (being removed) never touched headerDeps at all.
+- ROADMAP success criteria updated to reflect this — no standalone `getHeader()` utility will exist
+
+### Feature-Slice Build Strategy
+- **Build must pass after every removal step** — no intermediate broken states
+- Execution order:
+  1. CCC DAO utility (adds new code, nothing breaks)
+  2. Replace all scattered DAO checks with CCC utility calls (all packages)
+  3. Remove `getHeader()`/`HeaderKey` and inline CCC calls at all call sites (all packages)
+  4. Remove SmartTransaction class and update all method signatures to `ccc.TransactionLike` (all packages)
+  5. Remove CapacityManager and update SDK call sites (utils + sdk)
+- Each step touches multiple packages but leaves `pnpm check:full` passing
+- **Roadmap updated**: Phases 4-5 reduced in scope since method signatures are already updated to `ccc.TransactionLike` in Phase 1
+
+### Method Signatures (CCC Pattern)
+- Follow CCC's convention: public APIs accept `ccc.TransactionLike` (flexible input), return `ccc.Transaction` (concrete)
+- Convert internally with `ccc.Transaction.from(txLike)` at method entry point
+- Consistent with how CCC's own udt/spore/type-id packages work
+
+### UdtHandler/UdtManager — Deferred
+- UdtHandler interface and UdtManager class **stay in @ickb/utils** for Phase 1
+- Their method signatures are updated from `SmartTransaction` to `ccc.TransactionLike` to keep the build green
+- Full replacement deferred to Phase 3+ (depends on CCC Udt integration investigation)
+- `addUdtHandlers()` call sites — Claude's discretion on replacement approach
+
+### CapacityManager — Fully Removed
+- CapacityManager is deleted from @ickb/utils
+- Only consumer is `@ickb/sdk` (`findCapacities()` in sdk.ts, constructor in constants.ts)
+- SDK call sites updated to use CCC's native cell finding
+
+### Removal Approach
+- **Clean delete** — no deprecation stubs, no migration comments, no breadcrumbs
+- File deletions + barrel export removal in the **same commit** (atomic)
+- Files deleted: `transaction.ts`, `capacity.ts` (from @ickb/utils)
+- Files kept: `udt.ts` (signatures updated), `utils.ts` (getHeader/HeaderKey removed), `codec.ts`, `heap.ts`, `index.ts`
+- `utils.ts` keeps its name — no rename needed
+
+### Claude's Discretion
+- `addUdtHandlers()` replacement strategy at call sites
+- CapacityManager replacement approach in SDK (CCC native equivalent)
+- Exact commit boundaries within each feature-slice step
+- CCC PR code style and test approach (follow CCC's vitest patterns)
+
+</decisions>
+
+<specifics>
+## Specific Ideas
+
+- **Script comparison must use `eq()`** — never compare just `codeHash`. Always compare the full Script (codeHash + hashType + args) using CCC's `Script.eq()` method. This applies across the entire codebase, not just the DAO check. Downstream agents must follow this pattern for all script identification.
+- NervosDao type script is invariant across mainnet, testnet, devnet — the code hash is a genesis constant. The CCC PR can reference this fact.
+- CCC's existing `Cell.isNervosDao(client)` is async and uses client resolution — the new utility should be consistent with this pattern.
+- The CCC PR should follow CCC's error class conventions: see `ErrorTransactionInsufficientCapacity` and `ErrorTransactionInsufficientCoin` in `transactionErrors.ts` for the pattern.
+
+</specifics>
+
+<deferred>
+## Deferred Ideas
+
+- **addOutput() DAO check** — Sync check in `Transaction.addOutput()` using hardcoded DAO script when outputs > 64. Deferred due to CCC maintainer acceptance concerns (hot path overhead, even though it only triggers past 64 outputs). Mentioned in CCC PR description as future possibility.
+- **getHeader as CCC contribution** — A unified header lookup function (`client.getHeader(key)`) could be contributed to CCC itself, making iCKB's wrapper unnecessary. Low priority since the wrapper is being removed and calls inlined.
+
+</deferred>
+
+---
+
+*Phase: 01-ickb-utils-smarttransaction-removal*
+*Context gathered: 2026-02-22*

From 092e2b652f16eadf1f7b28719900fc20c9301171 Mon Sep 17 00:00:00 2001
From: phroi <90913182+phroi@users.noreply.github.com>
Date: Sun, 22 Feb 2026 14:34:39 +0000
Subject: [PATCH 2/5] docs: reconcile planning docs with phase 1 decisions
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Align all planning and research docs with decisions from phase 1
context work:
- TransactionLike input / Transaction output convention (CCC pattern)
- getHeader()/HeaderKey removed entirely; CCC client calls inlined
- Phase→Step terminology in protocol descriptions (avoid roadmap
  confusion)
- Feature-slice approach noted in research docs (vs original
  per-package bottom-up suggestion)
- Phase 3 renamed to "CCC Udt Integration Investigation"
- CapacityManager deletion (not migration) clarified
- addCellDeps() is already on ccc.Transaction (no utility needed)
---
 .planning/REQUIREMENTS.md          | 52 +++++++++++-----------
 .planning/ROADMAP.md               | 69 +++++++++++++++---------------
 .planning/codebase/ARCHITECTURE.md | 12 +++---
 .planning/research/ARCHITECTURE.md | 69 +++++++++++++-----------------
 .planning/research/FEATURES.md     |  8 ++--
 .planning/research/PITFALLS.md     |  8 ++--
 .planning/research/STACK.md        | 12 +++---
 .planning/research/SUMMARY.md      | 10 +++--
 8 files changed, 116 insertions(+), 124 deletions(-)

diff --git a/.planning/REQUIREMENTS.md b/.planning/REQUIREMENTS.md
index 3f8f494..0c48a53 100644
--- a/.planning/REQUIREMENTS.md
+++ b/.planning/REQUIREMENTS.md
@@ -9,10 +9,10 @@ Requirements for initial milestone. Each maps to roadmap phases.
 
 ### SmartTransaction Removal
 
-- [ ] **SMTX-01**: All manager methods (`DaoManager`, `OrderManager`, `LogicManager`, `OwnedOwnerManager`, `CapacityManager`, `UdtManager`, `IckbUdtManager`) accept `ccc.Transaction` instead of `SmartTransaction`
+- [ ] **SMTX-01**: All manager method signatures across all 5 library packages accept `ccc.TransactionLike` instead of `SmartTransaction`, following CCC's convention (TransactionLike input, Transaction output); `CapacityManager` is deleted (not migrated)
 - [ ] **SMTX-02**: `SmartTransaction` class and its `completeFee()` override are deleted from `@ickb/utils`
 - [ ] **SMTX-03**: Fee completion uses CCC-native `ccc.Transaction.completeFeeBy()` or `completeFeeChangeToLock()` with DAO-aware capacity calculation
-- [ ] **SMTX-04**: Header caching delegates to `ccc.Client.cache` instead of `SmartTransaction.headers` map
+- [ ] **SMTX-04**: `getHeader()` function and `HeaderKey` type are removed from `@ickb/utils`; all call sites inline CCC client calls (`client.getTransactionWithHeader()`, `client.getHeaderByNumber()`); header caching handled transparently by `ccc.Client.cache`
 - [ ] **SMTX-05**: UDT handler registration (`addUdtHandlers()`) is replaced by direct `Udt` instance usage or standalone utility functions
 - [ ] **SMTX-06**: 64-output NervosDAO limit check is consolidated into a single utility function (currently scattered across 6 locations)
 - [ ] **SMTX-07**: `IckbUdtManager` multi-representation UDT balance logic (xUDT + receipts + deposits) survives removal intact -- conservation law `Input UDT + Input Receipts = Output UDT + Input Deposits` is preserved
@@ -31,7 +31,7 @@ Requirements for initial milestone. Each maps to roadmap phases.
 ### CCC Udt Integration
 
 - [ ] **UDT-01**: Feasibility assessment completed: can `IckbUdt extends udt.Udt` override `infoFrom()` or `getInputsInfo()`/`getOutputsInfo()` to account for receipt cells and deposit cells alongside xUDT cells
-- [ ] **UDT-02**: Header access pattern for receipt value calculation is designed -- determine whether `client.getCellWithHeader()`, `client.getHeaderByTxHash()`, or the existing `getHeader()` pattern is used within the Udt override
+- [ ] **UDT-02**: Header access pattern for receipt value calculation is designed -- determine whether `client.getCellWithHeader()`, `client.getHeaderByTxHash()`, or direct CCC client calls are used within the Udt override (`getHeader()` utility removed in Phase 1)
 - [ ] **UDT-03**: Decision documented: subclass CCC `Udt` vs. keep custom `UdtHandler` interface vs. hybrid approach
 - [ ] **UDT-04**: If subclassing is viable, `IckbUdt` class is implemented in `@ickb/core` with multi-representation balance calculation
 - [ ] **UDT-05**: If subclassing is not viable, `IckbUdtManager` is refactored to work with plain `ccc.Transaction` (no SmartTransaction dependency) while maintaining a compatible interface
@@ -79,28 +79,28 @@ Explicitly excluded. Documented to prevent scope creep.
 
 Which phases cover which requirements. Updated during roadmap creation.
 
-| Requirement | Phase | Status |
-|-------------|-------|--------|
-| SMTX-01 | Phase 5 | Pending |
-| SMTX-02 | Phase 1 | Pending |
-| SMTX-03 | Phase 6 | Pending |
-| SMTX-04 | Phase 1 | Pending |
-| SMTX-05 | Phase 4 | Pending |
-| SMTX-06 | Phase 1 | Pending |
-| SMTX-07 | Phase 5 | Pending |
-| SMTX-08 | Phase 6 | Pending |
-| SMTX-09 | Phase 7 | Pending |
-| SMTX-10 | Phase 4 | Pending |
-| DEDUP-01 | Phase 2 | Pending |
-| DEDUP-02 | Phase 2 | Pending |
-| DEDUP-03 | Phase 2 | Pending |
-| DEDUP-04 | Phase 2 | Pending |
-| DEDUP-05 | Phase 2 | Pending |
-| UDT-01 | Phase 3 | Pending |
-| UDT-02 | Phase 3 | Pending |
-| UDT-03 | Phase 3 | Pending |
-| UDT-04 | Phase 5 | Pending |
-| UDT-05 | Phase 5 | Pending |
+| Requirement | Phase | Status | Notes |
+|-------------|-------|--------|-------|
+| SMTX-01 | Phase 1 | Pending | Feature-slice: all signatures migrated to TransactionLike across all packages |
+| SMTX-02 | Phase 1 | Pending | |
+| SMTX-03 | Phase 6 | Pending | |
+| SMTX-04 | Phase 1 | Pending | getHeader()/HeaderKey removed, CCC client calls inlined |
+| SMTX-05 | Phase 4, 5 | Pending | addUdtHandlers() removed in Phase 1; replacement pattern finalized in Phase 4-5 after Phase 3 decision |
+| SMTX-06 | Phase 1 | Pending | DAO check contributed to CCC core via ccc-dev/ |
+| SMTX-07 | Phase 5 | Pending | |
+| SMTX-08 | Phase 6 | Pending | |
+| SMTX-09 | Phase 7 | Pending | |
+| SMTX-10 | Phase 4, 5 | Pending | Deprecated calls in dao/order (Phase 4) and core (Phase 5) |
+| DEDUP-01 | Phase 2 | Pending | |
+| DEDUP-02 | Phase 2 | Pending | |
+| DEDUP-03 | Phase 2 | Pending | |
+| DEDUP-04 | Phase 2 | Pending | |
+| DEDUP-05 | Phase 2 | Pending | |
+| UDT-01 | Phase 3 | Pending | |
+| UDT-02 | Phase 3 | Pending | |
+| UDT-03 | Phase 3 | Pending | |
+| UDT-04 | Phase 5 | Pending | |
+| UDT-05 | Phase 5 | Pending | |
 
 **Coverage:**
 - v1 requirements: 20 total
@@ -109,4 +109,4 @@ Which phases cover which requirements. Updated during roadmap creation.
 
 ---
 *Requirements defined: 2026-02-21*
-*Last updated: 2026-02-21 after roadmap creation*
+*Last updated: 2026-02-22 after Phase 1 context (feature-slice restructure)*
diff --git a/.planning/ROADMAP.md b/.planning/ROADMAP.md
index c8dfcae..e72cb3e 100644
--- a/.planning/ROADMAP.md
+++ b/.planning/ROADMAP.md
@@ -2,7 +2,7 @@
 
 ## Overview
 
-This roadmap delivers the v1 milestone: removing the abandoned SmartTransaction abstraction, adopting CCC-native utilities and UDT patterns, and verifying the entire 5-package library suite compiles and functions against plain `ccc.Transaction`. The work follows the package dependency graph bottom-up (`@ickb/utils` -> `@ickb/dao` + `@ickb/order` -> `@ickb/core` -> `@ickb/sdk`), with a parallel design investigation for CCC Udt integration that feeds into the `@ickb/core` refactor.
+This roadmap delivers the v1 milestone: removing the abandoned SmartTransaction abstraction, adopting CCC-native utilities and UDT patterns, and verifying the entire 5-package library suite compiles and functions against plain `ccc.Transaction`. Phase 1 uses a **feature-slice approach** — each removal is chased across all packages so the build stays green at every step, which front-loads method signature migration. Later phases handle UDT pattern finalization (after Phase 3 investigation), deprecated API replacement, SDK completion, and full verification.
 
 ## Phases
 
@@ -12,25 +12,27 @@ This roadmap delivers the v1 milestone: removing the abandoned SmartTransaction
 
 Decimal phases appear between their surrounding integers in numeric order.
 
-- [ ] **Phase 1: @ickb/utils SmartTransaction Removal** - Delete SmartTransaction class and its infrastructure; extract standalone utilities for header caching and DAO output limits
+- [ ] **Phase 1: SmartTransaction Removal (feature-slice)** - Delete SmartTransaction class and infrastructure across all packages; contribute 64-output DAO limit check to CCC core; migrate all method signatures to ccc.TransactionLike
 - [ ] **Phase 2: CCC Utility Adoption** - Replace local utility functions that duplicate CCC equivalents across all packages; preserve iCKB-unique utilities
 - [ ] **Phase 3: CCC Udt Integration Investigation** - Assess feasibility of subclassing CCC's Udt class for iCKB's multi-representation value; design header access pattern; document decision
-- [ ] **Phase 4: @ickb/dao and @ickb/order Migration** - Update DaoManager and OrderManager to accept plain ccc.Transaction; replace UDT handler registration pattern; replace deprecated CCC API calls
-- [ ] **Phase 5: @ickb/core Refactor** - Update all remaining managers to plain ccc.Transaction; implement IckbUdt class or refactor IckbUdtManager based on Phase 3 findings; preserve conservation law
+- [ ] **Phase 4: Deprecated CCC API Replacement** - Replace deprecated CCC API calls (`udtBalanceFrom`, etc.) with `@ckb-ccc/udt` equivalents in dao and order packages; finalize UDT handler replacement pattern based on Phase 3 findings
+- [ ] **Phase 5: @ickb/core UDT Refactor** - Implement IckbUdt class or refactor IckbUdtManager based on Phase 3 findings; preserve iCKB conservation law; replace deprecated CCC API calls in core
 - [ ] **Phase 6: SDK Completion Pipeline** - Wire IckbSdk facade to CCC-native fee completion; verify estimate() and maturity() work end-to-end
 - [ ] **Phase 7: Full Stack Verification** - Verify all 5 library packages compile clean with no SmartTransaction remnants and no type errors
 
 ## Phase Details
 
-### Phase 1: @ickb/utils SmartTransaction Removal
-**Goal**: SmartTransaction class and its dependent types (UdtHandler, UdtManager, CapacityManager) are removed from @ickb/utils; header caching and 64-output DAO limit check are consolidated into standalone utility functions
+### Phase 1: SmartTransaction Removal (feature-slice)
+**Goal**: SmartTransaction class, CapacityManager class are deleted; all manager method signatures across all 5 library packages accept `ccc.TransactionLike` instead of `SmartTransaction`; 64-output DAO limit check is contributed to CCC core; `getHeader()`/`HeaderKey` are removed and inlined. Each removal is chased across all packages — build stays green at every step.
 **Depends on**: Nothing (first phase)
-**Requirements**: SMTX-02, SMTX-04, SMTX-06
+**Requirements**: SMTX-01, SMTX-02, SMTX-04, SMTX-06
 **Success Criteria** (what must be TRUE):
-  1. `SmartTransaction` class, `UdtHandler` interface, `UdtManager` class, and `CapacityManager` class no longer exist in `@ickb/utils` source or exports
-  2. A standalone `getHeader()` utility function exists that delegates to `ccc.Client.cache` for header lookups instead of maintaining its own `Map<hexString, Header>`
-  3. A single `assertDaoOutputLimit(tx)` utility function exists that checks the 64-output NervosDAO limit, replacing the check currently scattered across 6 locations
-  4. `@ickb/utils` compiles successfully with the SmartTransaction-related code removed (downstream packages will have expected compilation errors until they are updated)
+  1. `SmartTransaction` class and `CapacityManager` class no longer exist in `@ickb/utils` source or exports
+  2. `UdtHandler` interface and `UdtManager` class remain in `@ickb/utils` with method signatures updated from `SmartTransaction` to `ccc.TransactionLike` (full replacement deferred to Phase 3+)
+  3. `getHeader()` function and `HeaderKey` type are removed from `@ickb/utils`; all call sites across dao/core/sdk inline CCC client calls (`client.getTransactionWithHeader()`, `client.getHeaderByNumber()`); `SmartTransaction.addHeaders()` call sites in DaoManager/LogicManager push to `tx.headerDeps` directly
+  4. A 64-output NervosDAO limit check exists in CCC core (via `ccc-dev/`): `completeFee()` safety net, standalone async utility, and `ErrorNervosDaoOutputLimit` error class; all 6+ scattered checks across dao/core packages are replaced with calls to this CCC utility
+  5. ALL manager method signatures across ALL 5 library packages accept `ccc.TransactionLike` instead of `SmartTransaction`, following CCC's convention (TransactionLike input, Transaction output with `Transaction.from()` conversion at entry point)
+  6. `pnpm check:full` passes after each feature-slice removal step — no intermediate broken states
 **Plans**: TBD
 
 Plans:
@@ -55,12 +57,12 @@ Plans:
 - [ ] 02-02: TBD
 
 ### Phase 3: CCC Udt Integration Investigation
-**Goal**: Clear, documented decision on whether IckbUdt should extend CCC's `udt.Udt` class for iCKB's multi-representation value (xUDT + receipts + deposits), with the header access pattern designed
+**Goal**: Clear, documented decision on whether IckbUdt should extend CCC's `udt.Udt` class for iCKB's multi-representation value (xUDT + receipts + deposits), with the header access pattern designed. This decision determines the replacement for UdtHandler/UdtManager (which remain in `@ickb/utils` with updated signatures after Phase 1).
 **Depends on**: Nothing (can proceed in parallel with Phases 1-2; design investigation, not code changes)
 **Requirements**: UDT-01, UDT-02, UDT-03
 **Success Criteria** (what must be TRUE):
   1. A written feasibility assessment exists answering: can `IckbUdt extends udt.Udt` override `getInputsInfo()`/`getOutputsInfo()` to account for receipt cells and deposit cells alongside xUDT cells, without breaking CCC's internal method chains
-  2. The header access pattern for receipt value calculation is designed and documented -- specifying whether `client.getCellWithHeader()`, `client.getHeaderByTxHash()`, or the existing `getHeader()` utility is used within the Udt override
+  2. The header access pattern for receipt value calculation is designed and documented -- specifying whether `client.getCellWithHeader()`, `client.getHeaderByTxHash()`, or direct CCC client calls are used within the Udt override (note: `getHeader()` was removed in Phase 1)
   3. A decision document exists with one of three outcomes: (a) subclass CCC Udt, (b) keep custom interface, (c) hybrid approach -- with rationale for the chosen path
 **Plans**: TBD
 
@@ -68,32 +70,31 @@ Plans:
 - [ ] 03-01: TBD
 - [ ] 03-02: TBD
 
-### Phase 4: @ickb/dao and @ickb/order Migration
-**Goal**: DaoManager and OrderManager accept plain `ccc.Transaction`; the UDT handler registration pattern (`addUdtHandlers()`) is replaced in these packages; deprecated CCC API calls are replaced with `@ckb-ccc/udt` equivalents
-**Depends on**: Phase 1 (SmartTransaction removed from utils)
+### Phase 4: Deprecated CCC API Replacement
+**Goal**: Deprecated CCC API calls are replaced with `@ckb-ccc/udt` equivalents in `@ickb/dao` and `@ickb/order`; UDT handler usage is finalized based on Phase 3 findings (method signatures and `addUdtHandlers()` removal already done in Phase 1)
+**Depends on**: Phase 1 (signatures migrated), Phase 3 (UDT decision — determines replacement pattern for UdtHandler usage)
 **Requirements**: SMTX-05, SMTX-10
 **Success Criteria** (what must be TRUE):
-  1. `DaoManager` methods in `@ickb/dao` accept `ccc.Transaction` as their transaction parameter (not `SmartTransaction`)
-  2. `OrderManager` methods in `@ickb/order` accept `ccc.Transaction` as their transaction parameter (not `SmartTransaction`)
-  3. No calls to `addUdtHandlers()` exist in `@ickb/dao` or `@ickb/order`; UDT-related operations use direct `Udt` instance methods or standalone utility functions
-  4. No calls to deprecated CCC APIs (`udtBalanceFrom`, `getInputsUdtBalance`, `getOutputsUdtBalance`, `completeInputsByUdt`) exist in `@ickb/dao` or `@ickb/order`
-  5. Both `@ickb/dao` and `@ickb/order` compile successfully
+  1. No calls to deprecated CCC APIs (`udtBalanceFrom`, `getInputsUdtBalance`, `getOutputsUdtBalance`, `completeInputsByUdt`) exist in `@ickb/dao` or `@ickb/order`
+  2. UDT-related operations in `@ickb/dao` and `@ickb/order` use the pattern chosen in Phase 3 (direct `Udt` instance methods, refactored UdtManager, or hybrid)
+  3. Both `@ickb/dao` and `@ickb/order` compile successfully
 **Plans**: TBD
 
 Plans:
 - [ ] 04-01: TBD
 - [ ] 04-02: TBD
 
-### Phase 5: @ickb/core Refactor
-**Goal**: All remaining managers (LogicManager, OwnedOwnerManager, IckbUdtManager) accept plain `ccc.Transaction`; IckbUdt class is implemented or IckbUdtManager is refactored based on Phase 3 findings; the iCKB conservation law is preserved through the refactor
-**Depends on**: Phase 3 (UDT decision), Phase 4 (dao+order done)
-**Requirements**: SMTX-01, SMTX-07, UDT-04, UDT-05
+### Phase 5: @ickb/core UDT Refactor
+**Goal**: IckbUdt class is implemented or IckbUdtManager is refactored based on Phase 3 findings; the iCKB conservation law is preserved through the refactor; deprecated CCC API calls are replaced in `@ickb/core`; UdtHandler/UdtManager are removed from `@ickb/utils` (manager method signatures already migrated to `ccc.TransactionLike` in Phase 1)
+**Depends on**: Phase 3 (UDT decision), Phase 4 (dao+order UDT pattern finalized)
+**Requirements**: SMTX-05, SMTX-07, SMTX-10, UDT-04, UDT-05
 **Success Criteria** (what must be TRUE):
-  1. ALL manager methods across ALL 5 library packages accept `ccc.Transaction` instead of `SmartTransaction` (this is the completion gate for SMTX-01 -- utils managers removed in Phase 1, dao+order managers updated in Phase 4, core managers updated here)
-  2. The iCKB conservation law (`Input UDT + Input Receipts = Output UDT + Input Deposits`) is enforced correctly in the refactored code -- multi-representation UDT balance logic survives intact
-  3. If Phase 3 concluded subclassing is viable: `IckbUdt extends udt.Udt` exists in `@ickb/core` with overridden `getInputsInfo()`/`getOutputsInfo()` that account for xUDT cells, receipt cells, and deposit cells
-  4. If Phase 3 concluded subclassing is not viable: `IckbUdtManager` is refactored to work with plain `ccc.Transaction` while maintaining a compatible interface for balance calculation
-  5. `@ickb/core` compiles successfully with no SmartTransaction imports
+  1. The iCKB conservation law (`Input UDT + Input Receipts = Output UDT + Input Deposits`) is enforced correctly in the refactored code -- multi-representation UDT balance logic survives intact
+  2. If Phase 3 concluded subclassing is viable: `IckbUdt extends udt.Udt` exists in `@ickb/core` with overridden `getInputsInfo()`/`getOutputsInfo()` that account for xUDT cells, receipt cells, and deposit cells
+  3. If Phase 3 concluded subclassing is not viable: `IckbUdtManager` is refactored to work with plain `ccc.Transaction` while maintaining a compatible interface for balance calculation
+  4. `UdtHandler` interface and `UdtManager` class are removed from `@ickb/utils` (their responsibilities absorbed by the Phase 3 outcome implementation)
+  5. No calls to deprecated CCC APIs exist in `@ickb/core`
+  6. `@ickb/core` compiles successfully with no SmartTransaction imports
 **Plans**: TBD
 
 Plans:
@@ -133,14 +134,14 @@ Plans:
 
 **Execution Order:**
 Phases execute in numeric order: 1 -> 2 -> 3 -> 4 -> 5 -> 6 -> 7
-(Note: Phase 3 could theoretically start in parallel with Phases 1-2, but sequential execution is configured)
+(Note: Phase 3 could start in parallel with Phases 1-2; Phase 4 now depends on Phase 3 in addition to Phase 1)
 
 | Phase | Plans Complete | Status | Completed |
 |-------|----------------|--------|-----------|
-| 1. @ickb/utils SmartTransaction Removal | 0/3 | Not started | - |
+| 1. SmartTransaction Removal (feature-slice) | 0/3 | Not started | - |
 | 2. CCC Utility Adoption | 0/2 | Not started | - |
 | 3. CCC Udt Integration Investigation | 0/2 | Not started | - |
-| 4. @ickb/dao and @ickb/order Migration | 0/2 | Not started | - |
-| 5. @ickb/core Refactor | 0/3 | Not started | - |
+| 4. Deprecated CCC API Replacement | 0/2 | Not started | - |
+| 5. @ickb/core UDT Refactor | 0/3 | Not started | - |
 | 6. SDK Completion Pipeline | 0/2 | Not started | - |
 | 7. Full Stack Verification | 0/1 | Not started | - |
diff --git a/.planning/codebase/ARCHITECTURE.md b/.planning/codebase/ARCHITECTURE.md
index 205f74d..77efff8 100644
--- a/.planning/codebase/ARCHITECTURE.md
+++ b/.planning/codebase/ARCHITECTURE.md
@@ -31,13 +31,13 @@ The iCKB protocol solves NervosDAO illiquidity by pooling DAO deposits and issui
 
 **Exchange Rate:** `iCKB_value = unoccupied_capacity * AR_0 / AR_m` where `AR_0 = 10^16` (genesis accumulated rate) and `AR_m` is the accumulated rate at the deposit block. CKB is inflationary; iCKB is not -- 1 iCKB represents an ever-increasing amount of CKB over time.
 
-**Deposit (2-Phase):**
-1. Phase 1: User deposits CKB into NervosDAO -> receives a Receipt cell (cannot calculate iCKB value yet because the block's accumulated rate isn't available during validation).
-2. Phase 2: Receipt cell is converted to iCKB xUDT tokens using the now-available accumulated rate from the deposit block header.
+**Deposit (2-Step):**
+1. Step 1: User deposits CKB into NervosDAO -> receives a Receipt cell (cannot calculate iCKB value yet because the block's accumulated rate isn't available during validation).
+2. Step 2: Receipt cell is converted to iCKB xUDT tokens using the now-available accumulated rate from the deposit block header.
 
-**Withdrawal (2-Phase):**
-1. Phase 1: User burns iCKB tokens -> creates a NervosDAO withdrawal request (using any mature deposit from the pool, not necessarily the user's original deposit).
-2. Phase 2: Standard NervosDAO withdrawal after 180-epoch maturity.
+**Withdrawal (2-Step):**
+1. Step 1: User burns iCKB tokens -> creates a NervosDAO withdrawal request (using any mature deposit from the pool, not necessarily the user's original deposit).
+2. Step 2: Standard NervosDAO withdrawal after 180-epoch maturity.
 
 **Soft Cap Penalty:** Deposits exceeding 100,000 iCKB-equivalent incur a 10% discount on the excess amount. This incentivizes standard-size deposits (~100k CKB) and prevents DoS via fragmentation. Formula: `final = amount - (amount - 100000) / 10` when `amount > 100000`.
 
diff --git a/.planning/research/ARCHITECTURE.md b/.planning/research/ARCHITECTURE.md
index b444de2..a0c2458 100644
--- a/.planning/research/ARCHITECTURE.md
+++ b/.planning/research/ARCHITECTURE.md
@@ -104,10 +104,9 @@ The refactored architecture replaces `SmartTransaction` (a subclass of `ccc.Tran
 |                     Utilities Layer                                  |
 |  +---------------------------------------------------------------+ |
 |  |              @ickb/utils                                      | |
-|  |  addCellDeps() | getHeader() utilities                        | |
 |  |  collect() | unique() | binarySearch() | MinHeap              | |
 |  |  (NO SmartTransaction, NO UdtHandler, NO UdtManager,         | |
-|  |   NO CapacityManager -- replaced by CCC completeInputs*)     | |
+|  |   NO CapacityManager, NO getHeader()/HeaderKey)               | |
 |  +---------------------------------------------------------------+ |
 |                              |                                      |
 +------------------------------+--------------------------------------+
@@ -132,7 +131,7 @@ Current state: `SmartTransaction extends ccc.Transaction` adding:
 - Overrides `getInputsUdtBalance()`/`getOutputsUdtBalance()` to delegate to handlers
 - Overrides `getInputsCapacity()` to account for DAO withdrawal profit
 
-Target: All manager methods accept `ccc.Transaction` instead of `SmartTransaction`. Each concern migrates to a different place:
+Target: All manager methods accept `ccc.TransactionLike` instead of `SmartTransaction` (following CCC's convention: TransactionLike input, Transaction output). Each concern migrates to a different place:
 
 | SmartTransaction feature | Replacement |
 |---|---|
@@ -140,8 +139,8 @@ Target: All manager methods accept `ccc.Transaction` instead of `SmartTransactio
 | `completeFee()` override that calls UDT handlers | App-level orchestration: call `ickbUdt.completeBy(tx, signer)` then `tx.completeFeeBy(signer)` |
 | `getInputsUdtBalance()`/`getOutputsUdtBalance()` overrides | `IckbUdt.getInputsInfo(client, tx)` / `IckbUdt.getOutputsInfo(client, tx)` |
 | `getInputsCapacity()` DAO profit override | Not needed -- CCC's `Transaction.getInputsCapacity()` handles DAO profit natively via `getInputsCapacityExtra()` -> `Cell.getDaoProfit()` |
-| `headers` map + `addHeaders()` + `getHeader()` | CCC's Client Cache (already caches headers). For header-dependent operations, pass headers explicitly or use client.getHeader() |
-| `addCellDeps()` deduplication | Utility function `addCellDeps(tx, deps)` (simple, no class needed) |
+| `headers` map + `addHeaders()` + `getHeader()` | Removed entirely. `getHeader()` call sites inline CCC client calls (`client.getTransactionWithHeader()`, `client.getHeaderByNumber()`). `addHeaders()` call sites push to `tx.headerDeps` directly. CCC's Client Cache handles caching transparently |
+| `addCellDeps()` deduplication | `tx.addCellDeps()` (already on `ccc.Transaction`) |
 | `SmartTransaction.default()` | `ccc.Transaction.default()` |
 
 **2. CCC Udt Adoption for iCKB**
@@ -245,7 +244,7 @@ This approach works because:
 - The `completeBy()` and `completeChangeToLock()` methods automatically work with the overridden balance calculation
 - Input outpoints are available in `tx.inputs`, enabling header fetching for receipt/deposit value calculation
 
-**Note:** This is a preliminary design. The viability of subclassing CCC's `Udt` is an open question to be resolved during Phase 3 (UDT Investigation). See Pitfall 2 in PITFALLS.md for the risks involved.
+**Note:** This is a preliminary design. The viability of subclassing CCC's `Udt` is an open question to be resolved during Phase 3 (CCC Udt Integration Investigation). See Pitfall 2 in PITFALLS.md for the risks involved.
 
 **3. DAO Capacity Calculation**
 
@@ -255,7 +254,7 @@ This approach works because:
 
 | Component | Owns | Does NOT Own |
 |-----------|------|-------------|
-| `@ickb/utils` | `addCellDeps()` utility, `getHeader()` utility, `collect()`, `unique()`, `binarySearch()`, `MinHeap`, `BufferedGenerator`, codec utilities | No SmartTransaction, no UdtHandler, no UdtManager, no CapacityManager (replaced by CCC's `completeInputsByCapacity`), no header caching |
+| `@ickb/utils` | `collect()`, `unique()`, `binarySearch()`, `MinHeap`, `BufferedGenerator`, codec utilities | No SmartTransaction, no UdtHandler, no UdtManager, no CapacityManager, no `getHeader()`/`HeaderKey` (all removed; CCC equivalents used directly) |
 | `@ickb/dao` | `DaoManager` (deposit/withdraw/requestWithdrawal/find operations), `DaoCell` wrapping | No UDT concerns, no DAO capacity utility (CCC handles natively) |
 | `@ickb/order` | `OrderManager` (convert/mint/match/melt/find), `OrderMatcher`, `OrderCell`/`MasterCell`/`OrderGroup`, `Info`/`Ratio`/`OrderData` entities | No direct UDT balancing (delegates to UDT handler) |
 | `@ickb/core` | `LogicManager` (deposit/completeDeposit/findReceipts/findDeposits), `OwnedOwnerManager`, `IckbUdt extends udt.Udt` (triple-representation balancing), iCKB exchange rate math | No generic UDT handling |
@@ -336,18 +335,18 @@ orderManager.mint(tx: SmartTransaction, lock, info, amounts): void
 logicManager.deposit(tx: SmartTransaction, qty, amount, lock): void
 ```
 
-**After (plain ccc.Transaction):**
+**After (plain ccc.TransactionLike / ccc.Transaction):**
 ```typescript
-// All managers accept plain ccc.Transaction
-daoManager.deposit(tx: ccc.Transaction, capacities, lock): void
-orderManager.mint(tx: ccc.Transaction, lock, info, amounts): void
-logicManager.deposit(tx: ccc.Transaction, qty, amount, lock): void
+// All managers accept ccc.TransactionLike, return ccc.Transaction (CCC convention)
+daoManager.deposit(tx: ccc.TransactionLike, capacities, lock): ccc.Transaction
+orderManager.mint(tx: ccc.TransactionLike, lock, info, amounts): ccc.Transaction
+logicManager.deposit(tx: ccc.TransactionLike, qty, amount, lock): ccc.Transaction
 ```
 
 The key difference: managers no longer call `tx.addUdtHandlers()` or `tx.addHeaders()`. Instead:
 - CellDeps are added via `tx.addCellDeps()` (already exists on `ccc.Transaction`)
 - UDT completion is handled by the caller at transaction completion time
-- Headers are fetched from the client cache or passed explicitly when needed
+- Headers are fetched via inlined CCC client calls; `getHeader()`/`HeaderKey` removed entirely
 
 ## Architectural Patterns
 
@@ -522,42 +521,34 @@ export async function completeIckbTransaction(
 
 **Do this instead:** Use CCC's `Udt` class directly. For iCKB-specific behavior, subclass `Udt`.
 
-## Build Order (Dependency-Driven)
+## Build Order
 
-The refactoring must proceed bottom-up through the dependency graph:
+> **Note:** This research originally suggested a per-package bottom-up build order. The actual ROADMAP uses a **feature-slice approach** instead — each removal is chased across ALL packages so the build stays green at every step. See `.planning/ROADMAP.md` for the authoritative 7-phase structure (SmartTransaction Removal → CCC Utility Adoption → Udt Investigation → Deprecated API Replacement → Core UDT Refactor → SDK Completion → Full Verification). App migration is deferred to a future milestone.
+
+The dependency graph still applies to the order of operations within each feature-slice:
 
 ```
-Phase 1: @ickb/utils (foundation -- remove SmartTransaction, UdtHandler, UdtManager)
-    |
-    v
-Phase 2: @ickb/dao (update DaoManager to use ccc.Transaction)
-    |
-    v
-Phase 3: @ickb/order (update OrderManager to use ccc.Transaction)
-    |     \
-    v      v
-Phase 4: @ickb/core (update LogicManager, OwnedOwnerManager; create IckbUdt)
+@ickb/utils  (foundation -- SmartTransaction, CapacityManager, getHeader live here)
     |
-    v
-Phase 5: @ickb/sdk (update IckbSdk to use new completion pipeline)
-    |
-    v
-Phase 6: Apps (migrate bot, interface, tester from Lumos to CCC + new packages)
+    +---> @ickb/dao   (depends on utils)
+    +---> @ickb/order  (depends on utils)
+    |         |
+    +---> @ickb/core   (depends on dao + utils)
+              |
+          @ickb/sdk    (depends on all above)
 ```
 
-**Rationale for this order:**
-
-1. **@ickb/utils first** because every other package imports it. SmartTransaction removal here unlocks all downstream changes.
+**Rationale for dependency order within feature-slices:**
 
-2. **@ickb/dao before @ickb/order and @ickb/core** because `@ickb/core` depends on `@ickb/dao` (LogicManager has a DaoManager). Order and core can be done in parallel since neither depends on the other directly.
+1. **@ickb/utils first** because every other package imports it. Changes to exports here affect all downstream packages.
 
-3. **@ickb/core before @ickb/sdk** because IckbUdt (in core) must exist before SDK can use it for the completion pipeline.
+2. **@ickb/dao and @ickb/order in parallel** since neither depends on the other directly.
 
-4. **@ickb/sdk before apps** because apps consume the SDK.
+3. **@ickb/core after dao** because `@ickb/core` depends on `@ickb/dao` (LogicManager has a DaoManager).
 
-5. **Apps last** because they are the consumers and the most work. The migrated faucet/sampler apps will also need updating if their SmartTransaction usage changes.
+4. **@ickb/sdk last** because it depends on all domain packages.
 
-**Critical dependency:** The `IckbUdt` subclass design in Phase 4 is the riskiest and most uncertain part. If CCC's `Udt` class cannot be subclassed effectively for the triple-representation model, the architecture may need to fall back to a wrapper pattern rather than inheritance. Phase-specific research recommended.
+**Critical dependency:** The `IckbUdt` subclass design (ROADMAP Phase 3 investigation) is the riskiest and most uncertain part. If CCC's `Udt` class cannot be subclassed effectively for the triple-representation model, the architecture may need to fall back to a wrapper pattern rather than inheritance.
 
 ## Integration Points
 
@@ -573,7 +564,7 @@ Phase 6: Apps (migrate bot, interface, tester from Lumos to CCC + new packages)
 
 | Boundary | Communication | Notes |
 |----------|---------------|-------|
-| Utils <-> Domain | Domain managers call utility functions, use CapacityManager | Direction: domain calls utils, never reverse |
+| Utils <-> Domain | Domain managers call utility functions (collect, unique, binarySearch, codec) | Direction: domain calls utils, never reverse. CapacityManager removed; CCC's `completeInputsByCapacity()` replaces it |
 | Domain <-> SDK | SDK instantiates and orchestrates domain managers | SDK owns manager lifecycle via `getConfig()` |
 | SDK <-> Apps | Apps call SDK methods, receive immutable snapshots | `SystemState` is a plain readonly object, no circular dependency |
 | Domain <-> CCC Udt | `IckbUdt extends udt.Udt` in `@ickb/core` | CCC Udt is the extension point; iCKB does NOT modify CCC code |
diff --git a/.planning/research/FEATURES.md b/.planning/research/FEATURES.md
index 6f42507..6f3ba5a 100644
--- a/.planning/research/FEATURES.md
+++ b/.planning/research/FEATURES.md
@@ -87,8 +87,8 @@ SmartTransaction Removal (TS-1)
 
 CCC Udt Investigation (D-2)
     |
-    +-- requires --> SmartTransaction Removal (TS-1)
-    |                   (must understand new API shape first)
+    +-- can parallel --> SmartTransaction Removal (TS-1)
+    |                   (design investigation, no code changes -- can proceed in parallel)
     |
     +-- informs --> Multi-representation UDT (D-1)
                         (whether to use Udt interface or custom)
@@ -122,7 +122,7 @@ npm Publication (TS-11)
 - **TS-1 (SmartTransaction Removal) is the critical path.** Every downstream task depends on it. It must happen first and must preserve D-1 (multi-representation UDT) and D-3 (conversion preview) functionality.
 - **TS-5 (Bot Migration) validates the entire stack.** The bot exercises deposits, withdrawals, order matching, fee completion, and UDT balancing under real conditions. It is the integration test for the library suite.
 - **TS-4 (Lumos Removal) is the final gate.** It can only happen after all three legacy apps are migrated. It removes `@ickb/lumos-utils`, `@ickb/v1-core`, and all `@ckb-lumos/*` from the monorepo.
-- **D-2 (CCC Udt Investigation) is exploratory.** It should not block other work. Findings inform the API design of D-1 but the library can ship with a custom `UdtHandler` interface regardless.
+- **D-2 (CCC Udt Investigation) is exploratory.** It can proceed in parallel with SmartTransaction removal (design investigation, not code changes). Findings inform the API design of D-1 but the library can ship with a custom `UdtHandler` interface regardless.
 - **CCC PR #328 (FeePayer) is external.** Track it but do not depend on it. Design the SmartTransaction replacement so that FeePayer can be adopted later if it merges.
 
 ## MVP Definition
@@ -131,7 +131,7 @@ npm Publication (TS-11)
 
 Minimum viable state for npm publication of clean CCC-aligned library packages.
 
-- [ ] **TS-1: SmartTransaction removal** -- Replace with utility functions on `ccc.Transaction`. This is the single most important task. All manager methods must accept `ccc.Transaction` instead of `SmartTransaction`.
+- [ ] **TS-1: SmartTransaction removal** -- Replace with utility functions on `ccc.Transaction`. This is the single most important task. All manager methods must accept `ccc.TransactionLike` instead of `SmartTransaction` (CCC convention: TransactionLike input, Transaction output).
 - [ ] **TS-2: CCC utility deduplication** -- Adopt CCC equivalents for `max`/`min`/`gcd`/`isHex`/`hexFrom`.
 - [ ] **TS-3: Clean public API** -- Audit exports, ensure intentional public surface, proper type exports.
 - [ ] **TS-5: Bot migration** -- Validates the library packages work end-to-end under production conditions.
diff --git a/.planning/research/PITFALLS.md b/.planning/research/PITFALLS.md
index 73fc3c9..3581de5 100644
--- a/.planning/research/PITFALLS.md
+++ b/.planning/research/PITFALLS.md
@@ -16,7 +16,7 @@ SmartTransaction's design buries critical side effects in method overrides that
 
 **How to avoid:**
 1. Before removing anything, catalog every SmartTransaction-specific method used across the codebase. The complete list: `addUdtHandlers`, `addHeaders`, `getHeader`, `hasUdtHandler`, `getUdtHandler`, `encodeUdtKey`, `encodeHeaderKey`, `completeFee` (override), `getInputsCapacity` (override), `getInputsUdtBalance` (override), `getOutputsUdtBalance` (override), `clone` (override with shared maps), `copy` (override with map merging), `default` (override), `from` (override).
-2. Design the replacement as standalone functions for the UDT completion concern (`completeUdtChange(tx, signer)`) and header dep management (`getHeader(client, tx, key)`). Note: `getInputsCapacity` DAO profit accounting does NOT need a utility — CCC's `Transaction.getInputsCapacity()` handles this natively via `getInputsCapacityExtra()` → `Cell.getDaoProfit()`. Validate that each original override has a corresponding replacement (utility function or CCC-native method).
+2. Design the replacement as standalone functions for the UDT completion concern (`completeUdtChange(tx, signer)`). Note: `getInputsCapacity` DAO profit accounting does NOT need a utility — CCC's `Transaction.getInputsCapacity()` handles this natively via `getInputsCapacityExtra()` → `Cell.getDaoProfit()`. Header management: `getHeader()` and `HeaderKey` are removed entirely; call sites inline CCC client calls (`client.getTransactionWithHeader()`, `client.getHeaderByNumber()`); `addHeaders()` call sites push to `tx.headerDeps` directly. Validate that each original override has a corresponding replacement (inlined CCC call or CCC-native method).
 3. Write characterization tests BEFORE refactoring: for a known set of inputs, capture the exact `completeFee` output (number of added inputs, whether change was added) and the exact `getInputsCapacity` return value. Run these tests against the new utility functions.
 
 **Warning signs:**
@@ -41,7 +41,7 @@ Concretely, `IckbUdtManager.getInputsUdtBalance` currently (a) counts xUDT balan
 The temptation is to make `IckbUdt extends Udt` so that CCC's generic transaction completion (`completeBy`, `completeInputsByBalance`) "just works" for iCKB. But iCKB's multi-representation value model is fundamentally incompatible with the assumption that UDT balance = sum of `u128 LE` fields in matching type cells. The CCC `Udt` class was designed for standard xUDT tokens, not for protocol-specific tokens with conservation laws spanning multiple cell types.
 
 **How to avoid:**
-1. The preferred approach (see ARCHITECTURE.md and STACK.md) is to subclass `Udt` as `IckbUdt`, overriding `getInputsInfo()`/`getOutputsInfo()` rather than `infoFrom()`. This avoids the `CellAnyLike` limitation (no outPoint for header fetching) while keeping CCC's completion methods functional. However, this is an **open design question** to be resolved during Phase 3 (UDT Investigation).
+1. The preferred approach (see ARCHITECTURE.md and STACK.md) is to subclass `Udt` as `IckbUdt`, overriding `getInputsInfo()`/`getOutputsInfo()` rather than `infoFrom()`. This avoids the `CellAnyLike` limitation (no outPoint for header fetching) while keeping CCC's completion methods functional. However, this is an **open design question** to be resolved during Phase 3 (CCC Udt Integration Investigation).
 2. If subclassing proves unviable, the fallback is to keep multi-representation accounting in iCKB-specific standalone functions (refactored from `IckbUdtManager`), using CCC's `Udt` only for standard xUDT operations (cell discovery, basic balance reading).
 3. Whichever approach is chosen, ensure that CCC's `Udt.completeInputsByBalance()` does not inadvertently add receipt or deposit cells as if they were standard xUDT inputs. Verify that the conservation law (`input_udt + input_receipts = output_udt + input_deposits`) is enforced correctly by the overridden methods.
 4. Always add required `headerDeps` explicitly -- CCC's client cache handles header fetching performance, but `headerDeps` must be on the transaction for on-chain validation.
@@ -53,7 +53,7 @@ The temptation is to make `IckbUdt extends Udt` so that CCC's generic transactio
 - CCC's generic `completeInputsByBalance()` selecting cells that trigger the conservation law unexpectedly
 
 **Phase to address:**
-Phase 3 (UDT Investigation). The UDT handling architecture must be settled before core implementation (Phase 5), because the apps currently use `SmartTransaction.completeFee` which delegates to `IckbUdtManager.completeUdt`. Phase 3 is specifically designed to resolve this design question.
+Phase 3 (CCC Udt Integration Investigation). The UDT handling architecture must be settled before core implementation (Phase 5), because the apps currently use `SmartTransaction.completeFee` which delegates to `IckbUdtManager.completeUdt`. Phase 3 is specifically designed to resolve this design question.
 
 ---
 
@@ -260,7 +260,7 @@ How roadmap phases should address these pitfalls.
 | Pitfall | Prevention Phase | Verification |
 |---------|------------------|--------------|
 | SmartTransaction implicit behaviors lost | Phase 1 (Library refactor) | Characterization tests pass: `completeFee` output matches, `getInputsCapacity` return matches, headers present in `headerDeps` |
-| CCC Udt subclassing for multi-representation value | Phase 3 (UDT Investigation) | Design decision documented: subclass viability confirmed or fallback approach chosen; conservation law preservation verified in either case |
+| CCC Udt subclassing for multi-representation value | Phase 3 (CCC Udt Integration Investigation) | Design decision documented: subclass viability confirmed or fallback approach chosen; conservation law preservation verified in either case |
 | Exchange rate divergence | Phase 1 (Library refactor, test infrastructure) | Cross-validation test suite exists with known Rust contract outputs; tests pass in CI |
 | Conservation law violation during app migration | Future milestone (App migration) | Migrated bot produces byte-identical transactions to Lumos bot for the same inputs; testnet validation passes |
 | Molecule codec byte layout mismatch | Phase 1 (Library refactor, test infrastructure) | Codec roundtrip tests exist for all 6 entity types; expected hex strings match Molecule schema |
diff --git a/.planning/research/STACK.md b/.planning/research/STACK.md
index 2ba9f40..bc89b8d 100644
--- a/.planning/research/STACK.md
+++ b/.planning/research/STACK.md
@@ -64,7 +64,6 @@ This research focuses on the CCC APIs and patterns that should be adopted as par
 | `ScriptDeps` interface | `packages/utils/src/utils.ts` | iCKB-specific manager composition pattern |
 | `ValueComponents` interface | `packages/utils/src/utils.ts` | iCKB-specific dual-value abstraction |
 | `ExchangeRatio` interface | `packages/utils/src/utils.ts` | iCKB-specific exchange rate abstraction |
-| `HeaderKey` type + `getHeader()` | `packages/utils/src/utils.ts` | See analysis below |
 
 ### CCC `@ckb-ccc/udt` Package
 
@@ -92,7 +91,7 @@ Use `@ckb-ccc/udt` because:
 | `getOutputsUdtBalance()` override | `Udt.getOutputsBalance()` | Direct method on Udt instance |
 | `getInputsCapacity()` override (DAO profit) | `ccc.Transaction.getInputsCapacity()` | CCC's base implementation now calls `getExtraCapacity()` per input, which includes DAO profit via `Cell.getDaoProfit()` |
 | Header caching (`headers` map) | `ccc.Client.cache` (ClientCacheMemory) | Headers cached automatically by Client on fetch |
-| `addHeaders()` / `getHeader()` | `client.getHeaderByHash()` / `client.getHeaderByNumber()` with auto-caching | CCC caches confirmed headers |
+| `addHeaders()` / `getHeader()` | Removed. Call sites inline CCC client calls (`client.getTransactionWithHeader()`, `client.getHeaderByNumber()`); `addHeaders()` call sites push to `tx.headerDeps` directly | CCC caches confirmed headers |
 | `addUdtHandlers()` | `udt.addCellDeps(tx)` | Cell deps added directly by Udt instance |
 | `default()` factory | `ccc.Transaction.default()` | Same pattern, no extra state |
 | `clone()` with shared state | `ccc.Transaction.clone()` | No shared state needed without udtHandlers/headers maps |
@@ -104,10 +103,9 @@ SmartTransaction's `headers` map served two purposes:
 1. **Performance:** Avoid re-fetching headers
 2. **Correctness:** Ensure headers are in `headerDeps` when needed for DAO calculations
 
-CCC's `Client.cache` handles purpose (1) -- all `getHeaderByHash()` and `getHeaderByNumber()` calls are cached if the header is confirmed. Purpose (2) -- adding to `headerDeps` -- must be handled explicitly by iCKB code. The `getHeader()` utility function in `utils.ts` should become a standalone function that:
-- Fetches the header via `client.getHeaderByHash/Number/getTransaction`
-- Adds the header hash to `tx.headerDeps` if not present
-- Does NOT cache (CCC Client handles that)
+CCC's `Client.cache` handles purpose (1) -- all `getHeaderByHash()` and `getHeaderByNumber()` calls are cached if the header is confirmed. Purpose (2) -- adding to `headerDeps` -- is handled by inlining CCC client calls at each call site.
+
+**Decision (from Phase 1 context):** `getHeader()` function and `HeaderKey` type are removed entirely from `@ickb/utils`. Call sites inline CCC client calls: `txHash` lookups use `(await client.getTransactionWithHeader(hash))?.header`, `number` lookups use `await client.getHeaderByNumber(n)`. `addHeaders()` call sites in DaoManager/LogicManager push to `tx.headerDeps` directly.
 
 ### Critical Design Decision: DAO Profit in getInputsCapacity
 
@@ -155,7 +153,7 @@ Create `IckbUdt extends Udt` that overrides `getInputsInfo()` and `getOutputsInf
 
 **Implementation sketch:** See ARCHITECTURE.md "Pattern 2: IckbUdt Subclass" for the full code example with `getInputsInfo()` override.
 
-**Note:** This is a preliminary design. The viability of subclassing CCC's `Udt` is an open question to be resolved during Phase 3 (UDT Investigation). See Pitfall 2 in PITFALLS.md for the risks involved.
+**Note:** This is a preliminary design. The viability of subclassing CCC's `Udt` is an open question to be resolved during Phase 3 (CCC Udt Integration Investigation). See Pitfall 2 in PITFALLS.md for the risks involved.
 
 **Header fetching within `getInputsInfo()`:**
 
diff --git a/.planning/research/SUMMARY.md b/.planning/research/SUMMARY.md
index 689ef8e..8b1465e 100644
--- a/.planning/research/SUMMARY.md
+++ b/.planning/research/SUMMARY.md
@@ -61,7 +61,7 @@ The library already implements all differentiators (D-3 through D-8, D-10): matu
 The architecture shifts from a God-object transaction (SmartTransaction carrying UDT handlers + header cache + overridden behaviors) to a layered composition model: plain `ccc.Transaction` for state, standalone utility functions for concerns like header dep management, `IckbUdt extends udt.Udt` for iCKB-specific balance calculation, and an explicit completion pipeline at the call site (complete UDT first, then CKB capacity, then fee). The build order is strictly bottom-up through the dependency graph.
 
 **Major components:**
-1. `@ickb/utils` — transaction utilities (`addCellDeps`, `getHeader`), async data utilities (`collect`, `unique`, `binarySearch`, `MinHeap`); NO SmartTransaction, NO UdtHandler, NO UdtManager after refactor
+1. `@ickb/utils` — async data utilities (`collect`, `unique`, `binarySearch`, `MinHeap`), codec utilities; NO SmartTransaction, NO UdtHandler, NO UdtManager, NO CapacityManager, NO `getHeader()`/`HeaderKey` after refactor
 2. `@ickb/dao` + `@ickb/order` — domain managers operating on plain `ccc.Transaction`; add cell deps directly; no UDT awareness
 3. `@ickb/core` — `IckbUdt extends udt.Udt` overriding `getInputsInfo()` and `getOutputsInfo()` for triple-representation balance; `LogicManager` and `OwnedOwnerManager` for iCKB protocol operations
 4. `@ickb/sdk` — `IckbSdk` facade orchestrating all managers; explicit completion pipeline: `ickbUdt.completeBy(tx, signer)` then `tx.completeFeeBy(signer)`
@@ -95,6 +95,8 @@ await signer.sendTransaction(completedTx);
 
 ## Implications for Roadmap
 
+> **Note:** The phase structure below was a pre-roadmap research suggestion. The actual ROADMAP (`.planning/ROADMAP.md`) uses a different 7-phase feature-slice approach: SmartTransaction Removal → CCC Utility Adoption → Udt Investigation → Deprecated API Replacement → Core UDT Refactor → SDK Completion → Full Verification. App migration (bot, interface, tester) is deferred to a future milestone. The research findings below still inform the roadmap decisions.
+
 Based on research, suggested phase structure:
 
 ### Phase 1: Library Foundation Refactor
@@ -104,8 +106,8 @@ Based on research, suggested phase structure:
 **Avoids:** Pitfalls 1 (SmartTransaction implicit behaviors), 3 (exchange rate divergence), 4 (64-output limit), 6 (codec byte layout)
 **Sub-phases (dependency-driven):**
 1a. Test infrastructure: characterization tests for SmartTransaction behaviors; codec roundtrip tests; exchange rate cross-validation fixtures
-1b. `@ickb/utils`: remove SmartTransaction, UdtHandler, UdtManager; adopt CCC utility equivalents; add `addCellDeps`/`getHeader` utility functions
-1c. `@ickb/dao` + `@ickb/order` (parallel): update all manager methods from `SmartTransaction` to `ccc.Transaction`
+1b. `@ickb/utils`: remove SmartTransaction, CapacityManager, `getHeader()`/`HeaderKey`; adopt CCC utility equivalents
+1c. `@ickb/dao` + `@ickb/order` (parallel): update all manager methods from `SmartTransaction` to `ccc.TransactionLike`
 1d. `@ickb/core`: create `IckbUdt extends udt.Udt`; update LogicManager/OwnedOwnerManager
 1e. `@ickb/sdk`: implement explicit completion pipeline; update IckbSdk facade
 **Research flag:** Phase 1d needs careful investigation — the `IckbUdt` subclassing approach is architecturally sound (confirmed by both STACK.md and ARCHITECTURE.md research) but the header-access-in-`getInputsInfo` pattern requires verification against the CCC `Udt` API.
@@ -163,7 +165,7 @@ Standard patterns (skip research-phase):
 
 ### Gaps to Address
 
-- **Resolved — CCC Udt override point:** Both ARCHITECTURE.md and STACK.md now agree on overriding `getInputsInfo()`/`getOutputsInfo()` (not `infoFrom()`). The `infoFrom()` approach was ruled out because `CellAnyLike` lacks `outPoint`, which is needed for header fetching in receipt/deposit value calculation. Final confirmation of CCC's internal method chains still needed during Phase 3 (UDT Investigation).
+- **Resolved — CCC Udt override point:** Both ARCHITECTURE.md and STACK.md now agree on overriding `getInputsInfo()`/`getOutputsInfo()` (not `infoFrom()`). The `infoFrom()` approach was ruled out because `CellAnyLike` lacks `outPoint`, which is needed for header fetching in receipt/deposit value calculation. Final confirmation of CCC's internal method chains still needed during Phase 3 (CCC Udt Integration Investigation).
 - **Resolved — DAO profit in CCC `getInputsCapacity`:** Verified from CCC source (transaction.ts lines 1860-1883) that `Transaction.getInputsCapacity()` handles DAO profit natively via `getInputsCapacityExtra()` → `CellInput.getExtraCapacity()` → `Cell.getDaoProfit()`. No standalone utility needed. SmartTransaction's override of `getInputsCapacity()` can be dropped without replacement.
 - **CCC PR #328 (FeePayer) tracking:** Design the SmartTransaction replacement so FeePayer can be adopted as a drop-in improvement if the PR merges. Do not block on it.
 - **Bot key logging security:** PITFALLS.md notes the faucet already has a private key logging bug. The bot migration must include an explicit security audit of all logging paths.

From 5ad270b70c2a6d49681f4310725d1d03b982e2cc Mon Sep 17 00:00:00 2001
From: phroi <90913182+phroi@users.noreply.github.com>
Date: Sun, 22 Feb 2026 14:34:46 +0000
Subject: [PATCH 3/5] docs: correct codebase documentation

- STACK.md: add ccc-dev workspace entries to pnpm-workspace.yaml
  listing; fix .pnpmfile.cjs description (workspace:* not link:)
- STRUCTURE.md: update ccc-dev directory tree (add patch.sh, push.sh,
  status.sh, tsgo-filter.sh; remove obsolete tsc.mjs)
---
 .planning/codebase/STACK.md     | 9 ++++++++-
 .planning/codebase/STRUCTURE.md | 7 +++++--
 2 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/.planning/codebase/STACK.md b/.planning/codebase/STACK.md
index b54fed8..e55b1be 100644
--- a/.planning/codebase/STACK.md
+++ b/.planning/codebase/STACK.md
@@ -73,6 +73,13 @@
 packages:
   - packages/*
   - apps/*
+  - ccc-dev/ccc/packages/*
+  - "!ccc-dev/ccc/packages/demo"
+  - "!ccc-dev/ccc/packages/docs"
+  - "!ccc-dev/ccc/packages/examples"
+  - "!ccc-dev/ccc/packages/faucet"
+  - "!ccc-dev/ccc/packages/playground"
+  - "!ccc-dev/ccc/packages/tests"
 
 catalog:
   '@ckb-ccc/core': ^1.12.2
@@ -109,7 +116,7 @@ The repo supports using a local development build of CCC for testing unpublished
 
 **`.pnpmfile.cjs`:**
 - A pnpm `readPackage` hook that auto-discovers all packages in `ccc-dev/ccc/packages/*/package.json`
-- When `ccc-dev/ccc/` exists, overrides all `@ckb-ccc/*` dependency versions in the workspace with `link:` references to the local build
+- When `ccc-dev/ccc/` exists, overrides all `@ckb-ccc/*` dependency versions in the workspace with `workspace:*` (CCC packages are listed in `pnpm-workspace.yaml`, but catalog specifiers resolve to semver ranges before workspace linking, so the hook forces `workspace:*` to ensure local packages are used)
 - Applies to `dependencies`, `devDependencies`, and `optionalDependencies`
 - Effect: all workspace packages transparently use the local CCC build instead of npm versions
 
diff --git a/.planning/codebase/STRUCTURE.md b/.planning/codebase/STRUCTURE.md
index 1d7ac8d..ab551cc 100644
--- a/.planning/codebase/STRUCTURE.md
+++ b/.planning/codebase/STRUCTURE.md
@@ -74,9 +74,12 @@
 │   │   ├── REFS                    # Pinned branch HEADs
 │   │   └── resolutions/            # Merge conflict resolutions
 │   ├── ccc/                        # Gitignored: ephemeral CCC clone (auto-generated)
+│   ├── patch.sh                    # Rewrites CCC exports to .ts source, creates deterministic commit
+│   ├── push.sh                     # Pushes local CCC changes upstream
 │   ├── record.sh                   # Records new pins with AI Coworker conflict resolution
 │   ├── replay.sh                   # Deterministically rebuilds ccc/ from pins
-│   └── tsc.mjs                     # TypeScript compilation script override
+│   ├── status.sh                   # Checks if ccc-dev/ccc/ has pending custom work
+│   └── tsgo-filter.sh              # Wrapper around tsgo filtering CCC diagnostics
 ├── reference/                      # Read-only reference repos (git-ignored, clone via `pnpm reference`)
 │   ├── contracts/                 # Rust on-chain contracts
 │   │   └── scripts/contracts/
@@ -309,7 +312,7 @@
     // ... methods
   }
   ```
-- Transaction methods: Accept `SmartTransaction`, call `.addCellDeps()`, `.addInput()`, `.addOutput()`
+- Transaction methods: Accept `ccc.TransactionLike`, return `ccc.Transaction`, call `.addCellDeps()`, `.addInput()`, `.addOutput()`
 - Finding methods: Use async generators for lazy cell discovery
 - Type checkers: Implement `isFoo(cell)` methods for type verification
 

From 31ddf91dfeb25981f97f558fbd600b47fb09e8eb Mon Sep 17 00:00:00 2001
From: phroi <90913182+phroi@users.noreply.github.com>
Date: Sun, 22 Feb 2026 15:10:31 +0000
Subject: [PATCH 4/5] chore: update agent configuration

- Add symlink note (CLAUDE.md -> AGENTS.md via pnpm coworker)
- Promote Learn directive to bold header for visibility
- Add Knowledge section with CKB Script.eq() comparison rule
- PR links: present as clickable markdown link, not raw URL
---
 AGENTS.md | 22 +++++++++++++++-------
 1 file changed, 15 insertions(+), 7 deletions(-)

diff --git a/AGENTS.md b/AGENTS.md
index 76cc8ba..ba0eb5c 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -1,23 +1,27 @@
 # AI Coworker Configuration
 
-This file is the tool-agnostic agent config:
+## Meta
 
 - **Learn**: When a non-obvious constraint causes a failure, leave a concise note here and a detailed comment at the relevant location
+- `CLAUDE.md` is a symlink to this file, created by `pnpm coworker`
 - Refer to yourself as "AI Coworker" in docs and comments, not by product or company name
 - Never add AI tool attribution or branding to PR descriptions, commit messages, or code comments
 - Do not install or use `gh` CLI
+
+## Workflows
+
 - **Routine Pre-PR Validation**: `pnpm check:full`, it wipes derived state and regenerates from scratch. If `ccc-dev/ccc/` has pending work, the wipe is skipped to prevent data loss — re-record or push CCC changes first for a clean validation
-- **Open a PR**: Push the branch, then construct and present a GitHub compare URL
-  (`quick_pull=1`) to the user. Base branch is `master`. Prefill "title" (concise, under 70 chars) and "body" (markdown with ## Why and ## Changes sections)
+- **Open a PR**: Push the branch, then present a clickable markdown link `[title](url)` where the URL is a GitHub compare URL (`quick_pull=1`). Base branch is `master`. Prefill "title" (concise, under 70 chars) and "body" (markdown with ## Why and ## Changes sections)
 - **Fetch PR review comments**: Use the GitHub REST API via curl. Fetch all three comment types (issue comments, reviews, and inline comments). Reviewers reply asynchronously — poll every minute until comments arrive
 - **Copy to clipboard**:
-  ```
+
+  ```sh
   head -c -1 <<'EOF' | wl-copy
   content goes here
   EOF
   ```
 
-# CCC Local Development (ccc-dev/)
+## CCC Local Development (ccc-dev/)
 
 The `ccc-dev/` system uses a record/replay mechanism for deterministic builds of a local CCC fork:
 
@@ -29,10 +33,14 @@ The `ccc-dev/` system uses a record/replay mechanism for deterministic builds of
 - `ccc-dev/patch.sh` rewrites CCC package exports to point at `.ts` source instead of `.d.ts`, then creates a deterministic git commit (fixed author/date) so record and replay produce the same `pins/HEAD` hash. This is why imports from `@ckb-ccc/*` resolve to TypeScript source files inside `node_modules` — it is not a bug
 - `ccc-dev/tsgo-filter.sh` is a bash wrapper around `tsgo` that filters out diagnostics originating from `ccc-dev/ccc/`. CCC source does not satisfy this repo's strict tsconfig (`verbatimModuleSyntax`, `noUncheckedIndexedAccess`, `noImplicitOverride`), so the wrapper suppresses those errors while still reporting errors in stack source
 
-# Reference Repos
+## Reference Repos
 
 `reference/` contains read-only clones (project knowledge, dependency sources, etc.) fetched via `pnpm reference`. To refresh, delete the directory and re-run `pnpm reference`
 
-# Versioning
+## Versioning
 
 All packages use version `1001.0.0` (Epoch Semantic Versioning), managed by changesets (`pnpm changeset`)
+
+## Knowledge
+
+- Always compare CKB scripts using full `Script.eq()` (codeHash + hashType + args), never just `codeHash`. Partial comparison silently matches wrong scripts

From 14db037944274b4fa540cde14f5142b2e1bc7381 Mon Sep 17 00:00:00 2001
From: phroi <90913182+phroi@users.noreply.github.com>
Date: Sun, 22 Feb 2026 15:10:37 +0000
Subject: [PATCH 5/5] chore: update lockfile

Dependency version bumps (claude-code 2.1.50, tsgo dev.20260221.1).
---
 pnpm-lock.yaml | 84 +++++++++++++++++++++++++-------------------------
 1 file changed, 42 insertions(+), 42 deletions(-)

diff --git a/pnpm-lock.yaml b/pnpm-lock.yaml
index 85e52a4..3c78474 100644
--- a/pnpm-lock.yaml
+++ b/pnpm-lock.yaml
@@ -18,7 +18,7 @@ importers:
     devDependencies:
       '@anthropic-ai/claude-code':
         specifier: latest
-        version: 2.1.49
+        version: 2.1.50
       '@changesets/changelog-github':
         specifier: ^0.5.2
         version: 0.5.2
@@ -30,7 +30,7 @@ importers:
         version: 9.39.3
       '@typescript/native-preview':
         specifier: latest
-        version: 7.0.0-dev.20260220.1
+        version: 7.0.0-dev.20260221.1
       '@vitest/coverage-v8':
         specifier: 3.2.4
         version: 3.2.4(vitest@3.2.4(@types/node@24.10.13)(jiti@2.6.1)(lightningcss@1.31.1)(yaml@2.8.2))
@@ -539,7 +539,7 @@ importers:
         version: 4.3.0(prettier@3.8.1)(typescript@5.9.3)
       tsdown:
         specifier: 0.19.0-beta.3
-        version: 0.19.0-beta.3(@typescript/native-preview@7.0.0-dev.20260220.1)(synckit@0.11.12)(typescript@5.9.3)
+        version: 0.19.0-beta.3(@typescript/native-preview@7.0.0-dev.20260221.1)(synckit@0.11.12)(typescript@5.9.3)
       typescript:
         specifier: ^5.9.2
         version: 5.9.3
@@ -972,7 +972,7 @@ importers:
         version: 4.3.0(prettier@3.8.1)(typescript@5.9.3)
       tsdown:
         specifier: 0.19.0-beta.3
-        version: 0.19.0-beta.3(@typescript/native-preview@7.0.0-dev.20260220.1)(synckit@0.11.12)(typescript@5.9.3)
+        version: 0.19.0-beta.3(@typescript/native-preview@7.0.0-dev.20260221.1)(synckit@0.11.12)(typescript@5.9.3)
       typescript:
         specifier: ^5.9.2
         version: 5.9.3
@@ -1203,8 +1203,8 @@ packages:
     resolution: {integrity: sha512-30iZtAPgz+LTIYoeivqYo853f02jBYSd5uGnGpkFV0M3xOt9aN73erkgYAmZU43x4VfqcnLxW9Kpg3R5LC4YYw==}
     engines: {node: '>=6.0.0'}
 
-  '@anthropic-ai/claude-code@2.1.49':
-    resolution: {integrity: sha512-PonEmTZlB5IZbBu9TmtOpGZnupU7OxOXTsJKcXE/4Ak5qp3ptN1wSBRdgKYnn6GDYhXijTXuVVwrCQU+NAgwPA==}
+  '@anthropic-ai/claude-code@2.1.50':
+    resolution: {integrity: sha512-urrhY4IRuLHFoEYb6pjRy6sbDE8TH886zwRvIAPS4Tz51MeGVomZet4EajqxX6+IOKbJNbf4IHL3fTzI0vcKXA==}
     engines: {node: '>=18.0.0'}
     hasBin: true
 
@@ -2810,43 +2810,43 @@ packages:
     resolution: {integrity: sha512-q+SL+b+05Ud6LbEE35qe4A99P+htKTKVbyiNEe45eCbJFyh/HVK9QXwlrbz+Q4L8SOW4roxSVwXYj4DMBT7Ieg==}
     engines: {node: ^18.18.0 || ^20.9.0 || >=21.1.0}
 
-  '@typescript/native-preview-darwin-arm64@7.0.0-dev.20260220.1':
-    resolution: {integrity: sha512-VZQHVaLYTpa3wfCLcFD5cfnegr4iDtzBxV6yh3tys+HYePi4TXuAqct/dmziW0cpCo/UQ2KqAPGxwVO3YMDYJA==}
+  '@typescript/native-preview-darwin-arm64@7.0.0-dev.20260221.1':
+    resolution: {integrity: sha512-m3ttEpK+eXV7P06RVZZuSuUvNDj8psXODrMJRRQWpTNsk3qITbIdBSgOx2Q/M3tbQ9Mo2IBHt6jUjqOdRW9oZQ==}
     cpu: [arm64]
     os: [darwin]
 
-  '@typescript/native-preview-darwin-x64@7.0.0-dev.20260220.1':
-    resolution: {integrity: sha512-ieGtyz904rlme8YWauDpCqGbnOQQ5dzUyRKU25I7MNIaoZFf0vK5gMh3SLjHC7ayWxjrCa2ezH4ka8UmyWQcPg==}
+  '@typescript/native-preview-darwin-x64@7.0.0-dev.20260221.1':
+    resolution: {integrity: sha512-BNaNe3rox2rpkh5sWcnZZob6sDA/at9KK55/WSRAH4W+9dFReOLFAR9YXhKxrLGZ1QpleuIBahKbV8o037S+pA==}
     cpu: [x64]
     os: [darwin]
 
-  '@typescript/native-preview-linux-arm64@7.0.0-dev.20260220.1':
-    resolution: {integrity: sha512-nlOOABSQUe6ix/KOsZS3ALZ/sg9rhtp6SKtQnXO8X4+2XUlwVYS6nIrAQ5jG4+OsCvcESttNeHhBw817uNrsuA==}
+  '@typescript/native-preview-linux-arm64@7.0.0-dev.20260221.1':
+    resolution: {integrity: sha512-Y4jsvwDq86LXq63UYRLqCAd+nD1r6C2NVaGNR39H+c6D8SgOBkPLJa8quTH0Ir8E5bsR8vTN4E6xHY9jD4J2PA==}
     cpu: [arm64]
     os: [linux]
 
-  '@typescript/native-preview-linux-arm@7.0.0-dev.20260220.1':
-    resolution: {integrity: sha512-wMA63N6XLAkO0Ibq1Qz2zkQHF6oLynYh5+q1YayzWxp1FOas0oJUdNgVbiWeisAT4IEI9SmYtVwJJNTm/cwrwg==}
+  '@typescript/native-preview-linux-arm@7.0.0-dev.20260221.1':
+    resolution: {integrity: sha512-+/uyIw7vg4FyAnNpsCJHmSOhMiR2m56lqaEo1J5pMAstJmfLTTKQdJ1muIWCDCqc24k2U30IStHOaCqUerp/nQ==}
     cpu: [arm]
     os: [linux]
 
-  '@typescript/native-preview-linux-x64@7.0.0-dev.20260220.1':
-    resolution: {integrity: sha512-W7R/5ct/BGuPAmJuKFU0ZuLU2nzLA26XfoaoUHHoTLYRMMuY3LBv+7zKSUTlSGjayeWQ5KtDrfrY72LarWAXkQ==}
+  '@typescript/native-preview-linux-x64@7.0.0-dev.20260221.1':
+    resolution: {integrity: sha512-7agd5FtVLPp+gRMvsecSDmdQ/XM80q/uaQ6+Kahan9uNrCuPJIyMiAtJvCoYYgT1nXX2AjwZk39DH63fRaw/Mg==}
     cpu: [x64]
     os: [linux]
 
-  '@typescript/native-preview-win32-arm64@7.0.0-dev.20260220.1':
-    resolution: {integrity: sha512-FNXTr2lS1QLUB05jWjkBVwrDierNuxKduQq9ayloENJrsC8GfG1sXkfy8R021+ozP/D1LI/CFUn3hkB2vPXTsQ==}
+  '@typescript/native-preview-win32-arm64@7.0.0-dev.20260221.1':
+    resolution: {integrity: sha512-lXbsy5vDzS//oE0evX+QwZBwpKselXTd8H18lT42CBQo2hL2r0+w9YBguaYXrnGkAoHjDXEfKA2xii8yVZKVUg==}
     cpu: [arm64]
     os: [win32]
 
-  '@typescript/native-preview-win32-x64@7.0.0-dev.20260220.1':
-    resolution: {integrity: sha512-byHRyf4dOuKOADrs43tWyPhmAgqk+XrA/XOsJnGsxUKxPwots+gf9x5kg/IxTbB3QjPsVe/V9QdMl3//sUTCmQ==}
+  '@typescript/native-preview-win32-x64@7.0.0-dev.20260221.1':
+    resolution: {integrity: sha512-O02pfQlVlRTsBmp0hODs/bOHm2ic2kXZpIchBP5Qm0wKCp1Ytz/7i3SNT1gN47I+KC4axn/AHhFmkWQyIu9kRQ==}
     cpu: [x64]
     os: [win32]
 
-  '@typescript/native-preview@7.0.0-dev.20260220.1':
-    resolution: {integrity: sha512-trYXlG98/C7Q7pqnPrKo+ksXrWqWVMncCy2x0VftD2llfL99Z//g2mpB9TmzWeKgb4d1659ESvxTowCGnzMccw==}
+  '@typescript/native-preview@7.0.0-dev.20260221.1':
+    resolution: {integrity: sha512-tEUzcnj6pD+z1vANchRzhpPl+3RMD+xQRvIN//0+qjtP5zyYB5T+MIaAWycpKDwlHP9C13JnQgcgYnC+LlNkrg==}
     hasBin: true
 
   '@vitejs/plugin-basic-ssl@1.2.0':
@@ -4749,7 +4749,7 @@ snapshots:
       '@jridgewell/gen-mapping': 0.3.13
       '@jridgewell/trace-mapping': 0.3.31
 
-  '@anthropic-ai/claude-code@2.1.49':
+  '@anthropic-ai/claude-code@2.1.50':
     optionalDependencies:
       '@img/sharp-darwin-arm64': 0.34.5
       '@img/sharp-darwin-x64': 0.34.5
@@ -6361,36 +6361,36 @@ snapshots:
       '@typescript-eslint/types': 8.56.0
       eslint-visitor-keys: 5.0.0
 
-  '@typescript/native-preview-darwin-arm64@7.0.0-dev.20260220.1':
+  '@typescript/native-preview-darwin-arm64@7.0.0-dev.20260221.1':
     optional: true
 
-  '@typescript/native-preview-darwin-x64@7.0.0-dev.20260220.1':
+  '@typescript/native-preview-darwin-x64@7.0.0-dev.20260221.1':
     optional: true
 
-  '@typescript/native-preview-linux-arm64@7.0.0-dev.20260220.1':
+  '@typescript/native-preview-linux-arm64@7.0.0-dev.20260221.1':
     optional: true
 
-  '@typescript/native-preview-linux-arm@7.0.0-dev.20260220.1':
+  '@typescript/native-preview-linux-arm@7.0.0-dev.20260221.1':
     optional: true
 
-  '@typescript/native-preview-linux-x64@7.0.0-dev.20260220.1':
+  '@typescript/native-preview-linux-x64@7.0.0-dev.20260221.1':
     optional: true
 
-  '@typescript/native-preview-win32-arm64@7.0.0-dev.20260220.1':
+  '@typescript/native-preview-win32-arm64@7.0.0-dev.20260221.1':
     optional: true
 
-  '@typescript/native-preview-win32-x64@7.0.0-dev.20260220.1':
+  '@typescript/native-preview-win32-x64@7.0.0-dev.20260221.1':
     optional: true
 
-  '@typescript/native-preview@7.0.0-dev.20260220.1':
+  '@typescript/native-preview@7.0.0-dev.20260221.1':
     optionalDependencies:
-      '@typescript/native-preview-darwin-arm64': 7.0.0-dev.20260220.1
-      '@typescript/native-preview-darwin-x64': 7.0.0-dev.20260220.1
-      '@typescript/native-preview-linux-arm': 7.0.0-dev.20260220.1
-      '@typescript/native-preview-linux-arm64': 7.0.0-dev.20260220.1
-      '@typescript/native-preview-linux-x64': 7.0.0-dev.20260220.1
-      '@typescript/native-preview-win32-arm64': 7.0.0-dev.20260220.1
-      '@typescript/native-preview-win32-x64': 7.0.0-dev.20260220.1
+      '@typescript/native-preview-darwin-arm64': 7.0.0-dev.20260221.1
+      '@typescript/native-preview-darwin-x64': 7.0.0-dev.20260221.1
+      '@typescript/native-preview-linux-arm': 7.0.0-dev.20260221.1
+      '@typescript/native-preview-linux-arm64': 7.0.0-dev.20260221.1
+      '@typescript/native-preview-linux-x64': 7.0.0-dev.20260221.1
+      '@typescript/native-preview-win32-arm64': 7.0.0-dev.20260221.1
+      '@typescript/native-preview-win32-x64': 7.0.0-dev.20260221.1
 
   '@vitejs/plugin-basic-ssl@1.2.0(vite@6.4.1(@types/node@22.19.11)(jiti@2.6.1)(lightningcss@1.31.1)(yaml@2.8.2))':
     dependencies:
@@ -7703,7 +7703,7 @@ snapshots:
       glob: 13.0.5
       package-json-from-dist: 1.0.1
 
-  rolldown-plugin-dts@0.20.0(@typescript/native-preview@7.0.0-dev.20260220.1)(rolldown@1.0.0-beta.58)(typescript@5.9.3):
+  rolldown-plugin-dts@0.20.0(@typescript/native-preview@7.0.0-dev.20260221.1)(rolldown@1.0.0-beta.58)(typescript@5.9.3):
     dependencies:
       '@babel/generator': 7.29.1
       '@babel/parser': 7.29.0
@@ -7715,7 +7715,7 @@ snapshots:
       obug: 2.1.1
       rolldown: 1.0.0-beta.58
     optionalDependencies:
-      '@typescript/native-preview': 7.0.0-dev.20260220.1
+      '@typescript/native-preview': 7.0.0-dev.20260221.1
       typescript: 5.9.3
     transitivePeerDependencies:
       - oxc-resolver
@@ -7953,7 +7953,7 @@ snapshots:
     dependencies:
       typescript: 5.9.3
 
-  tsdown@0.19.0-beta.3(@typescript/native-preview@7.0.0-dev.20260220.1)(synckit@0.11.12)(typescript@5.9.3):
+  tsdown@0.19.0-beta.3(@typescript/native-preview@7.0.0-dev.20260221.1)(synckit@0.11.12)(typescript@5.9.3):
     dependencies:
       ansis: 4.2.0
       cac: 6.7.14
@@ -7964,7 +7964,7 @@ snapshots:
       obug: 2.1.1
       picomatch: 4.0.3
       rolldown: 1.0.0-beta.58
-      rolldown-plugin-dts: 0.20.0(@typescript/native-preview@7.0.0-dev.20260220.1)(rolldown@1.0.0-beta.58)(typescript@5.9.3)
+      rolldown-plugin-dts: 0.20.0(@typescript/native-preview@7.0.0-dev.20260221.1)(rolldown@1.0.0-beta.58)(typescript@5.9.3)
       semver: 7.7.4
       tinyexec: 1.0.2
       tinyglobby: 0.2.15