feat(cli): add interactive sorokeep init setup wizard

[Primex-Tech]

closes #370 feat(cli): add an interactive 'sorokeep init' setup wizard

What does this PR do?

Why?

Does this touch secret-key handling or transaction submission?

• Yes - see notes above
• No

Checklist

• Tests pass (npm test)
• Type check passes (npx tsc --noEmit)
• Lint passes (npm run lint)
• Tests cover the new functionality (TDD preferred - see CONTRIBUTING.md)
• No unnecessary dependencies added
• Commit messages follow conventional format
• No console.log in core logic
• ADR added if this is a significant design decision (see docs/adr)
• E2E sandbox tested, if this touches RPC or daemon behavior (see docs/e2e-sandbox.md)

[coderabbitai]

Actionable comments posted: 12

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/commands/init.ts`:
- Around line 63-74: Extract the duplicated initialization result flow from the
non-interactive and interactive branches into a shared helper that accepts the
resolved answers, invokes runInitWizard, handles unsuccessful results with the
existing error and exit behavior, saves the config, and prints the success
message. Replace both branch-specific copies with calls to this helper,
preserving their existing answer values and variable mappings.
- Around line 45-49: Update all failure guards in runInitWizard, including the
nonInteractive validation and the additional process.exit(1) sites, to
explicitly return immediately after process.exit(1). Ensure stubbed exits cannot
continue into saveConfig or success output while preserving the existing error
messages and exit behavior.
- Line 22: Remove the "testnet" default value from the .option call for
--network to allow the fallback chain to work correctly. Update the network
assignment to use the fallback pattern: for non-interactive mode, use network ??
existingConfig.network (or configuredNetwork), and for interactive mode, use
network || (await rl.question with the prompt) || existingConfig.network. This
preserves saved network configuration and makes the interactive prompt reachable
when no --network flag is provided.
- Around line 91-95: Update the guard configuration flow around enableGuard,
resolvedTargetTtlLedgers, and resolvedThresholdLedgers so TTL and threshold
prompts execute only when enableGuard is true; when disabled, retain or assign
appropriate non-prompt defaults while preserving the existing enabled behavior
and policy output.
- Around line 27-28: The `--guard-enabled` and `--guard-disabled` options are
mutually exclusive but currently both can be passed, with line 41 resolving them
post-hoc. Chain `.conflicts("guardDisabled")` to the `--guard-enabled` option
declaration and `.conflicts("guardEnabled")` to the `--guard-disabled` option
declaration so the CLI rejects contradictory input at parse time. Import Option
from commander if not already present to ensure the conflicts method is
available.

In `@src/core/init.ts`:
- Around line 64-65: Separate the alert threshold from the guard threshold in
the initialization flow: add a dedicated alert-threshold input with its own
default, validate it with isPositiveInteger like the other ledger settings, and
use it when writing alert_configs.threshold_ledgers. Keep thresholdLedgers
sourced only from answers.guardThresholdLedgers for the guard policy.
- Around line 98-103: The init flow around insertAlertConfig must be idempotent:
prevent repeated runs from creating duplicate alert_configs for the same
contract_id, channel_type, and channel_target. Update insertAlertConfig in the
repository, or perform an equivalent existence check before insertion, while
preserving updates to the existing contract and extension policy.
- Around line 82-110: Wrap the post-watch database writes in runInitWizard,
specifically insertAlertConfig and upsertExtensionPolicy, within a single
db.transaction(...) callback so both commit or roll back together. Keep
watchContract unchanged and preserve the existing write arguments and failure
handling.
- Around line 1-7: Remove the top-level registerBuiltinChannels() call from
src/core/init.ts and invoke it explicitly inside runInitWizard before any
getAlertChannel usage, or from the CLI bootstrap in src/index.ts. Preserve
channel availability while eliminating registration as an import-time side
effect.

In `@tests/commands/init.test.ts`:
- Around line 17-20: Update the init test’s saveConfig mock and assertions to
verify the expected saveConfig call contract without asserting permissions
applied by the mock. Add a focused test for the real saveConfig implementation
in config.ts that writes the file and verifies its mode is 0o600.
- Around line 33-62: Update the non-interactive error branches in
registerInitCommand to return immediately after process.exit, preventing
saveConfig from running. Then add tests covering --yes without --contract,
--channel-type, or --channel-target, and runInitWizard returning success: false
with an error; assert each reports the error, does not call saveConfig, and
preserves the existing successful flow.

In `@tests/core/init.test.ts`:
- Around line 99-132: Add tests in the init wizard suite for the unsupported
channel and watch-failure branches in runInitWizard: verify an unsupported
channelType returns the “Unsupported alert channel type” error without creating
persisted state, and mock watchContract to return success: false, then verify
the failure propagates and neither alert configuration nor extension policy is
written.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 4d23377b-e751-4b9d-93e2-1f82e89e7f77

📥 Commits

Reviewing files that changed from the base of the PR and between a9983ee and e5ca7c8.

📒 Files selected for processing (5)

• src/commands/init.ts
• src/core/init.ts
• src/index.ts
• tests/commands/init.test.ts
• tests/core/init.test.ts

📜 Review details

🧰 Additional context used

🪛 ast-grep (0.45.0)

tests/commands/init.test.ts

[warning] 17-17: Filesystem path is not a string literal; a request-/variable-derived path can enable path traversal. Validate and normalize the path before use.
Context: fs.writeFileSync(configPath, JSON.stringify(config))
Note: [CWE-22] Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal').

(detect-non-literal-fs-filename-typescript)

🔇 Additional comments (5)

src/index.ts (1)

22-22: LGTM!

Also applies to: 54-54

src/core/init.ts (1)

28-80: LGTM!

tests/core/init.test.ts (1)

14-42: LGTM!

Also applies to: 44-97

src/commands/init.ts (1)

9-14: LGTM!

Also applies to: 77-90

tests/commands/init.test.ts (1)

26-31: LGTM!