Should you build your own Bolt.new?

Build a closest honest personal substitute for Bolt.new in an empty repository.
Use TypeScript, Node.js 22, a VS Code extension, SQLite, and one user-supplied model API; do not offer alternative stacks.
The core loop is: generate and edit a small web project in a local sandbox from structured prompts, index the repository, propose patches, run approved commands, and preserve an auditable session log.
Make the first run work locally with one documented command.
Store all user data locally by default and make export straightforward.
Put secrets in .env, ship .env.example, and never commit credentials.
Create a VS Code sidebar with chat, selected-code actions, repository search, and a patch preview.
Index only the open repository and respect .gitignore plus a separate assistant ignore file.
Require explicit approval before reading outside the workspace or running any command.
Represent edits as unified diffs with accept, reject, partial apply, undo, and Git status checks.
Capture tool calls, model requests, command output, and patch decisions in a local session log.
Add token and cost estimates, provider errors, cancellation, tests, and an offline data-flow diagram.
Include clear empty, loading, success, and recoverable error states.
Add input validation, safe filenames, and graceful handling of unavailable APIs.
Write focused tests for the core transformation and one end-to-end happy path.
Create a README with setup, architecture, permissions, data location, and backup steps.
Do not add accounts, billing, telemetry, analytics, or a hosted control plane.
Do not claim to reproduce proprietary data, network liquidity, regulated access, or frontier infrastructure.
Deliberately leave out training or reproducing a frontier coding model.
Deliberately leave out unattended command execution outside a sandbox.
Deliberately leave out cloud workspaces, team policy, and enterprise support.
Finish by running the tests and listing the exact commands used.