# Questions

Blank answers are not blockers. Blank answers authorize AI best judgment using the highest-quality appropriate default for a local, deterministic, self-hosted personal agent chat workbench. Ask only for irreversible, expensive, credentialed, destructive, or product-defining forks.

Use AI best judgment to produce the highest-quality appropriate implementation. Full-suite mapped Buildprints default to production-grade architecture: auth/session/tenant boundaries, durable persistence, worker/runtime ownership, deployment shape, observability, CI/e2e proof, security controls, and maintainable code. Favor simplicity unless mapped product obligations or product goals prove more complexity is needed. Do not block on ordinary engineering choices. Ask only for irreversible, expensive, credentialed, destructive, or product-defining forks. Missing credentials block live proof only; they do not remove provider adapters, config contracts, tests, or runtime wiring from scope.

## 1. Product direction

Should Personal Agent Chat optimize for a single-user local operator workbench, a developer-extensible agent runtime, or a future hosted product?

AI best judgment default: single-user local operator workbench with extensible provider/tool/runtime boundaries and no hosted or multi-tenant claim.

## 2. Tech stack preferences

Which frontend, backend, runtime, storage, and deployment preferences should guide implementation?

AI best judgment default: choose a stack that can deliver a streaming WebUI/API, durable local persistence, provider adapters, contract tests, and browser/API proof without unnecessary infrastructure.

## 3. UX/UI preferences

What visual style, interaction density, accessibility posture, and workbench ergonomics should the UI use?

AI best judgment default: dense, utilitarian local workbench with chat as the primary surface, compact diagnostics, visible blocked states, keyboard-accessible controls, and browser/screenshot proof.

## 4. Architecture preferences

Which frontend/backend/domain boundaries, provider/tool adapter seams, worker ownership, and persistence architecture should be preferred?

AI best judgment default: modular monolith or similarly boring layered app with UI/controllers, API/application services, domain contracts, repositories, provider/tool adapters, worker/runtime services, and e2e tests.

## 5. Quality bar

Which typecheck, lint, test, build, browser/e2e, runtime trace, no-fake, and security gates are required before claims can upgrade?

AI best judgment default: production-grade local proof with deterministic provider tests, persistence roundtrips, denied-path tests, browser/e2e proof for the workbench, and non-upgrading blockers for unavailable live credentials or deployment.

## 6. Constraints / things to avoid

Which forbidden patterns, out-of-scope surfaces, provider credentials, external writes, destructive actions, or hosted claims must remain blocked?

AI best judgment default: no source code copy, no legacy public branding terms, no source UI clone, no live-provider claim without live proof, no in-memory product durability, no generic dashboard shell, and no shell/network/browser execution without explicit policy and proof.