Backlog — external-repo assessment of Effect-TS under the standing thesis: borrow patterns, not code. No commitment to build; this records the verdict + the one tractable follow-up.
What Effect-TS is
A TypeScript ecosystem (flagship effect, ~14.7k★, 30+ packages): a full functional effect system — typed errors, DI via Layer/Context, fiber concurrency, resource management (Scope), Schema (parse/validate), Config (typed config + secrets), Schedule (retry/backoff), plus @effect/platform (Command/FS), @effect/cli, @effect/sql. Effect v4 is in-progress in effect-smol (churn risk).
Verdict: do NOT adopt Effect as a dependency
It's a paradigm shift (fiber runtime, large API surface, steep learning curve) against kit's ethos — lean, local-first, minimal deps, plain Node. For a security tool it weighs double: you want a small, auditable dependency tree; Effect is the opposite. The wins (fibers, DI runtime) don't solve kit's actual problems.
Borrow these patterns, in ROI order
Redacted secret wrapper — highest ROI; the one thing worth building. Effect's Config.redacted yields a Redacted<string> that logs <redacted> and only releases the value via explicit Redacted.value. kit is secret-dense (memory.db, .env.local, vault) and worried about leakage to logs/memory — a small in-house newtype (toString → <redacted>, explicit .value) over secret values in the memory/log path serves "secrets never leak" directly, without pulling in any framework. Candidate for its own issue.- Typed result discipline (errors as values, exhaustive handling) around
SecurityCheckResult — kit mostly does this already; worth formalizing.
- parse-don't-validate for
.kit.toml.
Placement
The Redacted wrapper is product code in kit (secret hygiene). The rest are conventions → belong in dev-standard, not hard-coded. Same layering as the CodeScene decision (#45).
Already covered
kit already runs execFile with arg arrays (= @effect/platform Command's safe mode) and has hand-rolled retry/backoff — nothing to borrow there.
Sources
🤖 Generated with Claude Code
https://claude.ai/code/session_015ERHw6bVUz39sAuoQZ1iyg
Backlog — external-repo assessment of Effect-TS under the standing thesis: borrow patterns, not code. No commitment to build; this records the verdict + the one tractable follow-up.
What Effect-TS is
A TypeScript ecosystem (flagship
effect, ~14.7k★, 30+ packages): a full functional effect system — typed errors, DI via Layer/Context, fiber concurrency, resource management (Scope),Schema(parse/validate),Config(typed config + secrets),Schedule(retry/backoff), plus@effect/platform(Command/FS),@effect/cli,@effect/sql. Effect v4 is in-progress ineffect-smol(churn risk).Verdict: do NOT adopt Effect as a dependency
It's a paradigm shift (fiber runtime, large API surface, steep learning curve) against kit's ethos — lean, local-first, minimal deps, plain Node. For a security tool it weighs double: you want a small, auditable dependency tree; Effect is the opposite. The wins (fibers, DI runtime) don't solve kit's actual problems.
Borrow these patterns, in ROI order
Redactedsecret wrapper — highest ROI; the one thing worth building. Effect'sConfig.redactedyields aRedacted<string>that logs<redacted>and only releases the value via explicitRedacted.value. kit is secret-dense (memory.db,.env.local, vault) and worried about leakage to logs/memory — a small in-house newtype (toString → <redacted>, explicit.value) over secret values in the memory/log path serves "secrets never leak" directly, without pulling in any framework. Candidate for its own issue.SecurityCheckResult— kit mostly does this already; worth formalizing..kit.toml.Placement
The Redacted wrapper is product code in kit (secret hygiene). The rest are conventions → belong in dev-standard, not hard-coded. Same layering as the CodeScene decision (#45).
Already covered
kit already runs
execFilewith arg arrays (=@effect/platformCommand's safe mode) and has hand-rolled retry/backoff — nothing to borrow there.Sources
🤖 Generated with Claude Code
https://claude.ai/code/session_015ERHw6bVUz39sAuoQZ1iyg