Can I vibecode Amazon Q Developer?

Build the closest honest consolation tool inspired by Amazon Q Developer; do not claim to replace its structural moat.
Use exactly this stack: Python 3.12 + Typer + SQLite to wire it all together; do not offer alternative stacks or languages.
The core loop is: Build a repository-local AI developer assistant that indexes one codebase, calls one model, proposes diffs, runs tests, and records every change. Do not aim to be a general platform; focus on deep, reliable implementation of this specific core loop.
Ensure the first run works locally with a single documented command (e.g., a simple shell script or Typer command).
Store all user data locally by default, avoiding any external SaaS dependencies for core functionality (except the specific LLM API), and make data export straightforward via a dedicated API endpoint or script in standard formats like JSON.
Put all secrets, API keys, and database credentials in a `.env` file, ship a `.env.example`, and implement pre-commit hooks or CI checks to ensure credentials are never accidentally committed to version control.
Implement the smallest polished CLI interface that completes the core loop end to end. Use realistic sample data that is clearly labelled and easy to delete.
Store every conversation, context retrieval event, and proposed diff in the local SQLite database for auditability and durability.
Design all side effects to be idempotent and resilient. Allow users to easily undo or reject a proposed diff without side effects lingering.
Build in rate limiting, exponential backoff for API errors, execution cancellation for long-running generations, and a mechanism for secret rotation.
Ship a complete local setup with health checks, comprehensive test suites, database backup scripts, and clear documentation.
Design a minimal but polished terminal UI with clear states for empty, loading, validation, success, and failure, ensuring accessible keyboard navigation and sensible text formatting.
Implement strict input validation using modern libraries (like Pydantic), enforce safe data handling, and gracefully handle external API outages without crashing the application. Never log secrets or private file contents unnecessarily.
Write focused unit tests for the data model and the most important workflow, along with at least one robust end-to-end smoke test that proves the core loop works.
Create an exhaustive README detailing the setup process, system architecture, permission models, data storage locations, backup/restore steps, and limitations.
Strictly avoid adding multi-tenant user accounts, billing systems, telemetry, tracking analytics, ads, or third-party accounts.
Deliberately exclude these paid-product advantages: enterprise policy, telemetry, and support; frontier coding model quality; large-context infrastructure.
Do not fake integrations, network effects, proprietary data, model quality, compliance, or security claims. Where an external API is optional, keep the app useful without it and explain the degraded mode.
Finish by running the test suite, building the application, and outputting the exact commands used to verify the system. Fix errors rather than merely describing them.