diff --git a/PROJECT-PROFILE-WORKBOOK.md b/PROJECT-PROFILE-WORKBOOK.md
deleted file mode 100644
index e96c83c..0000000
--- a/PROJECT-PROFILE-WORKBOOK.md
+++ /dev/null
@@ -1,207 +0,0 @@
-# Project Profile Workbook
-
-Fill out this workbook once before deployment when you want the suite to ship with pre-staged defaults for build, tools, environment, workflow, and quality preferences.
-
-This version has been completed and should act as the human-readable source behind [DEPLOYMENT-PROFILE.md](./DEPLOYMENT-PROFILE.md).
-
-## How To Use This Workbook
-
-- Keep answers concise and specific.
-- Prefer durable defaults over task-specific preferences.
-- If a question does not matter for your projects, write `No strong preference`.
-- If your answer depends on project type, note the default and the main exception.
-- Treat this workbook as the source for pre-deployment staging, not a runtime questionnaire.
-
-## Global Defaults
-
-### 1. What repository types should this suite optimize for by default?
-Answer: Full-stack web apps.
-
-### 2. What operating systems, shells, and local environments should the agent assume first?
-Answer: Windows and PowerShell for local development. Keep Linux, Docker, and Unraid deployment realities in mind.
-
-### 3. What package managers, build tools, and task runners should the agent prefer when multiple options exist?
-Answer: Compatibility-first defaults and standard stack tooling.
-
-### 4. Which languages, runtimes, or frameworks should get first-class preference across deployments?
-Answer: Node and TypeScript first for application work, with Python acceptable for tooling and automation.
-
-### 5. What is your default testing philosophy before considering work complete?
-Answer: Run the most relevant local tests for the changed area by default, and broaden verification for risky changes.
-
-### 6. How cautious should the agent be about asking questions versus making reasonable assumptions?
-Answer: Ask-first when product intent or change risk is unclear.
-
-### 7. What documentation should usually be updated when behavior, setup, or workflows change?
-Answer: Readmes, Unraid install docs, roadmaps, and shipped summaries are all important and should usually be updated when changes matter.
-
-### 8. What UX and polish bar should the suite assume for user-facing changes?
-Answer: High polish by default.
-
-### 9. What release, rollout, and communication expectations should be standard?
-Answer: Provide a concise change summary by default and note rollout or migration impact when relevant.
-
-### 10. What kinds of risk should the suite optimize hardest against?
-Answer: Regressions and broken behavior.
-
-## Software Development Defaults
-
-### 1. What architecture style or system design bias should be the default?
-Answer: Favor modular boundaries and cleaner separation early.
-
-### 2. How should the suite balance frontend, backend, and full-stack execution by default?
-Answer: Full-stack by default.
-
-### 3. Which frameworks, libraries, or implementation patterns should be preferred first?
-Answer: Prefer mainstream modern patterns for the stack.
-
-### 4. What database and persistence assumptions should the agent make?
-Answer: Relational database first.
-
-### 5. How conservative should migration and schema-change work be?
-Answer: Be careful, but do not overengineer small schema changes.
-
-### 6. What dependency upgrade strategy should be assumed?
-Answer: Prefer small, safe, frequent upgrades with focused validation.
-
-### 7. What performance bar should the suite assume by default?
-Answer: Be proactive about performance on critical paths.
-
-### 8. What minimum security baseline should be applied to code changes?
-Answer: Basic secure defaults only: validate input, handle secrets safely, and respect auth boundaries.
-
-### 9. What observability and operability expectations should be normal?
-Answer: Good operational hygiene with meaningful logs and diagnostics for important paths.
-
-### 10. How aggressive should the agent be about refactoring and technical debt reduction while doing feature work?
-Answer: Use feature work as an opportunity to improve surrounding structure meaningfully when it helps the change.
-
-## Debugging Defaults
-
-### 1. Should debugging start with reproduction first, code inspection first, or whichever is fastest to verify?
-Answer: Use whichever path gives the fastest trustworthy signal.
-
-### 2. What logs, traces, or diagnostics should the agent expect to consult before guessing?
-Answer: Lean on logs and traces first.
-
-### 3. How should the agent behave during live or user-impacting incidents?
-Answer: Stabilize first, then diagnose more deeply.
-
-### 4. What is the preferred rollback, mitigation, or feature-flag strategy when risk is high?
-Answer: Prefer reversible mitigations such as flags, rollbacks, or partial disablement.
-
-### 5. How strongly should the agent try to add or update tests when fixing bugs?
-Answer: Add tests for higher-risk or recurring bugs.
-
-### 6. What level of root-cause explanation should be standard after a fix?
-Answer: Clearly explain cause, symptom, and why the fix works.
-
-### 7. What tradeoffs are acceptable when stabilizing an issue quickly?
-Answer: Avoid temporary compromises unless there is no safer path.
-
-### 8. When should observability improvements be bundled with a bug fix?
-Answer: For most medium or high-risk bugs, add enough signal to help next time.
-
-## Documentation Defaults
-
-### 1. How strongly should the suite treat documentation as part of normal implementation work?
-Answer: Docs are part of most meaningful changes unless clearly unnecessary.
-
-### 2. What onboarding depth should be the default for new repos or contributor workflows?
-Answer: Practical onboarding with prerequisites, setup steps, validation, and common gotchas.
-
-### 3. When should architecture decision records be created or updated?
-Answer: For major decisions and meaningful pattern shifts.
-
-### 4. What release-note or change-summary style should be standard?
-Answer: Concise, audience-aware summaries with user impact called out when relevant.
-
-### 5. What level of API or integration documentation is expected by default?
-Answer: Strong API and integration documentation by default.
-
-### 6. How much should examples, snippets, or command samples be favored in docs?
-Answer: Prefer examples for setup, APIs, and workflows where ambiguity hurts adoption.
-
-### 7. What documentation updates should be mandatory after behavior or workflow changes?
-Answer: Update docs for any meaningful user-facing, setup, or team workflow change.
-
-### 8. What types of documentation should be concise versus comprehensive?
-Answer: Balanced. Keep reference content concise and onboarding or operational content more complete.
-
-## UI/UX Defaults
-
-### 1. How strict should design-system adherence be by default?
-Answer: Strong preference for reuse, but custom patterns are acceptable when they clearly improve the experience.
-
-### 2. What accessibility baseline should every user-facing change meet?
-Answer: Do not assume extra accessibility work by default unless requested.
-
-### 3. What responsive behavior should be assumed for new or updated UI?
-Answer: Responsive by default for desktop and mobile.
-
-### 4. How strongly should the agent favor component reuse over local implementation?
-Answer: Reuse when it fits well, and create new abstractions only when they are likely to matter again.
-
-### 5. What clarity and copy standards should be assumed for interface text?
-Answer: Highly polished product-copy quality by default.
-
-### 6. How much motion, animation, or visual flourish is appropriate by default?
-Answer: Use motion and flourish actively enough to make the interface feel premium.
-
-### 7. Should the suite bias toward bold, distinctive UI or conservative continuity with existing patterns?
-Answer: Bold and distinctive by default, within reason.
-
-### 8. How detailed should UI work be before it is considered ready?
-Answer: High completeness with strong state coverage, copy quality, polish, and edge-case handling.
-
-## Marketing Defaults
-
-### 1. Which audience should marketing and messaging defaults prioritize first?
-Answer: Mixed audience, leaning technical and product-savvy.
-
-### 2. What voice and tone should be the baseline?
-Answer: Premium, distinctive, and persuasive.
-
-### 3. What level of proof, specificity, or technical grounding should marketing claims include?
-Answer: Claims should be persuasive but grounded in real features and outcomes.
-
-### 4. What launch-content formats should be standard by default?
-Answer: Broader launch kit: release notes, launch copy, landing page sections, and social or email variants.
-
-### 5. How important is SEO and evergreen discoverability relative to launch messaging?
-Answer: Balance both, but do not let SEO weaken clarity.
-
-### 6. What product-copy style should be the default?
-Answer: Strong product-copy polish with sharper differentiation and CTA energy.
-
-### 7. How should the suite frame differentiation and positioning?
-Answer: Conservative positioning that focuses on real value rather than aggressive comparison.
-
-### 8. What types of calls to action should be preferred?
-Answer: Clear, action-oriented CTAs without heavy urgency.
-
-## Brainstorming Defaults
-
-### 1. Should idea generation favor breadth, speed, novelty, practicality, or a specific balance?
-Answer: Favor breadth first.
-
-### 2. How many options should the agent generate by default before recommending one?
-Answer: Three options by default.
-
-### 3. What criteria should be used most often to score or compare ideas?
-Answer: User value, differentiation, and implementation realism.
-
-### 4. What prioritization method should be the default for roadmap or opportunity choices?
-Answer: Strategic fit, user value, and implementation cost.
-
-### 5. How should innovation be balanced against implementation realism?
-Answer: Balanced, but require a believable path to execution.
-
-### 6. What kind of roadmap framing should be standard?
-Answer: Short-to-medium horizon with practical sequencing.
-
-### 7. When should brainstorming output turn into a scoped implementation plan?
-Answer: Usually after a preferred option is selected.
-
-### 8. What types of ideas should usually be filtered out early?
-Answer: Do not filter too early. Raise concerns and explore alternatives with more value before narrowing.