jarvis/DEPLOYMENT-PROFILE.md

# Deployment Profile

Use this file to stage prefilled defaults before deploying the suite into other repositories.

This file is the canonical source of preloaded build, tool, environment, workflow, and quality preferences for the deployed bundle. Keep it concise enough to be read early in a session.

## Precedence

1. Destination repository instructions
2. This deployment profile
3. Generic `AGENTS.md`, hubs, and skill files

## How To Maintain This File

- Fill out [PROJECT-PROFILE-WORKBOOK.md](./PROJECT-PROFILE-WORKBOOK.md) first.
- Rewrite the answers here as agent-facing defaults, not as questions.
- Prefer short, durable defaults over long policy prose.
- Update this file when your preferred build, tool, or workflow defaults change materially.

## Global Defaults

- 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

- 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

- 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

- 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

- 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

- 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

- 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.