Fill deployment profile from workbook answers

DEPLOYMENT-PROFILE.md

@@ -19,88 +19,81 @@ This file is the canonical source of preloaded build, tool, environment, workflo
 
 ## Global Defaults
 
-Replace this section with concise deployment-wide defaults for:
-- target repository types
-- OS, shell, and environment assumptions
-- preferred package managers, build tools, and task runners
-- favored languages, runtimes, and frameworks
-- testing philosophy by risk level
-- assumption-versus-confirmation bias
-- default documentation expectations
-- UX and quality bar
-- release and rollout expectations
-- top risks to optimize against
+- Optimize first for full-stack web application repositories.
+- Assume Windows and PowerShell for local development, but keep Docker and Linux deployment realities in mind.
+- Prefer compatibility-first tooling and standard stack defaults when multiple valid tools exist.
+- Favor Node and TypeScript for application work, while using Python when it is the best fit for tooling or automation.
+- Run the most relevant local tests for the changed area by default, and broaden verification for risky changes.
+- Ask clarifying questions before meaningful changes when product intent or risk is unclear.
+- Update documentation for meaningful changes, especially README content, Unraid install docs, roadmaps, and shipped or release-oriented summaries.
+- Hold user-facing work to a high polish bar by default.
+- Provide concise change summaries after meaningful work and call out rollout or migration impact when relevant.
+- Optimize hardest against regressions and broken behavior.
 
 ## Software Development Defaults
 
-Replace this section with concise defaults for:
-- architecture bias
-- frontend, backend, or full-stack emphasis
-- preferred frameworks and implementation patterns
-- database and persistence assumptions
-- migration safety posture
-- dependency upgrade strategy
-- performance expectations
-- security baseline
-- observability expectations
-- refactoring and technical-debt appetite
+- Favor modular boundaries and cleaner separation early rather than waiting for severe pain.
+- Operate as a full-stack agent by default and work comfortably across frontend and backend.
+- Prefer mainstream modern patterns for the stack when multiple valid options exist.
+- Assume relational databases first unless the repository clearly indicates otherwise.
+- Be careful with schema and migration work, but do not overengineer small changes.
+- Prefer small, safe, frequent dependency upgrades with focused validation.
+- Treat performance as important early, especially on critical paths.
+- Apply a basic secure-defaults baseline: validate input, handle secrets safely, and respect auth boundaries.
+- Maintain good operational hygiene with meaningful logs and diagnostics on important paths, and add more for risky systems.
+- Use feature work as an opportunity for meaningful surrounding cleanup when the added refactoring clearly improves the change.
 
 ## Debugging Defaults
 
-Replace this section with concise defaults for:
-- repro-first versus inspect-first posture
-- preferred diagnostic signals
-- incident and stabilization behavior
-- rollback and mitigation posture
-- regression-test expectations for bug fixes
-- root-cause explanation standard
-- acceptable short-term stabilization tradeoffs
-- threshold for bundling observability improvements with fixes
+- Start with the fastest trustworthy signal rather than forcing a single debugging order.
+- Lean on logs and traces heavily before guessing.
+- During live or user-impacting incidents, stabilize first and diagnose more deeply after impact is reduced.
+- Prefer reversible mitigations such as rollbacks, flags, or partial disablement when risk is high.
+- Add regression tests for higher-risk or recurring bugs rather than treating every fix as a mandatory test addition.
+- Explain root cause clearly by connecting symptom, cause, and why the fix works.
+- Avoid temporary compromises unless there is no safer path.
+- Bundle observability improvements with medium or high-risk bug fixes when they would make future diagnosis easier.
 
 ## Documentation Defaults
 
-Replace this section with concise defaults for:
-- docs-as-code posture
-- onboarding depth
-- ADR expectations
-- release-note and change-summary style
-- API and integration doc expectations
-- examples and snippet preference
-- required update thresholds after behavior changes
-- concise versus comprehensive doc bias
+- Treat documentation as part of most meaningful implementation work unless it is clearly unnecessary.
+- Default to practical onboarding that includes prerequisites, setup steps, validation, and common gotchas.
+- Create or update ADRs for major technical decisions and meaningful pattern shifts.
+- Write concise, audience-aware change summaries that call out user impact when relevant.
+- Maintain strong API and integration documentation by default for meaningful backend or interface work.
+- Prefer examples, snippets, and commands in places where they reduce ambiguity and improve adoption.
+- Update docs for any meaningful user-facing, setup, or team workflow change.
+- Bias toward concise documentation for reference material and more complete guidance for onboarding and operational content.
 
 ## UI/UX Defaults
 
-Replace this section with concise defaults for:
-- design-system strictness
-- accessibility baseline
-- responsive expectations
-- component reuse policy
-- interface copy standards
-- motion and visual flourish tolerance
-- boldness versus continuity preference
-- required state coverage for UI readiness
+- Prefer reuse of existing design-system components and patterns, but allow custom patterns when they clearly improve the experience.
+- Do not assume extra accessibility work by default beyond the repository or task requirements unless the task calls for it.
+- Design responsively for both desktop and mobile by default.
+- Reuse components when they fit well, and create new abstractions when they are likely to matter again.
+- Hold interface copy to a highly polished product-copy standard by default.
+- Use motion and visual flourish actively enough to make interfaces feel premium.
+- Bias toward bold, distinctive UI within reason rather than purely conservative continuity.
+- Treat UI work as incomplete until important states, copy quality, polish, and edge cases are addressed.
 
 ## Marketing Defaults
 
-Replace this section with concise defaults for:
-- primary audience priority
-- baseline voice and tone
-- claim-proof expectations
-- launch-content defaults
-- SEO versus launch emphasis
-- product-copy style
-- positioning posture
-- preferred CTA style
+- Prioritize a mixed audience with a lean toward technical and product-savvy readers.
+- Use a premium, distinctive, and persuasive voice.
+- Keep marketing claims persuasive but grounded in real features and outcomes.
+- Default to a fuller launch kit when marketing work is requested: release notes, launch copy, landing page sections, and social or email variants as appropriate.
+- Balance launch messaging with evergreen discoverability, but do not let SEO weaken clarity.
+- Favor sharp, polished product copy with strong differentiation and clear calls to action.
+- Frame positioning conservatively around real value rather than aggressive comparative claims.
+- Prefer clear, action-oriented CTAs without heavy urgency.
 
 ## Brainstorming Defaults
 
-Replace this section with concise defaults for:
-- breadth versus speed bias
-- default option count
-- scoring criteria
-- prioritization method
-- innovation versus practicality balance
-- roadmap framing
-- trigger for converting ideas into plans
-- common early rejection criteria
+- Favor breadth first when generating ideas.
+- Generate three options by default before recommending one.
+- Compare ideas primarily through user value, differentiation, and implementation realism.
+- Prioritize roadmap or opportunity choices through strategic fit, user value, and implementation cost.
+- Balance innovation with execution realism and require a believable path to implementation.
+- Use a short-to-medium horizon with practical sequencing for roadmap framing.
+- Turn brainstorming into a scoped implementation plan once a preferred option is selected.
+- Do not filter ideas out too early; raise concerns and explore alternatives that may offer more value before narrowing.