System Requirements Document for lifestyle-cybersecurity

1. Introduction

lifestyle-cybersecurity is the project under which Brute is built: a Windows desktop cybersecurity / password-testing tool. Brute exists to find weak passwords before someone else does — it lets an authorized operator configure a credential test against an authorized target, run it as a monitored task with progress indicators and live logs, review the findings, and export reports and logs. All settings, records, and run history are stored locally; the product is local-first and requires no cloud.

The audience is technical but human: security testers and operators who run repeated test jobs and read logs for hours, and application administrators / maintainers who own the desktop configuration, the local store of settings and history, and the authorized external-service integrations, and who keep the packaged Windows build working on clean machines.

The product is delivered in six stages, all current: (1) requirements and research documenting what Brute does, who uses it, its main features, input and output formats, supported operating systems, and integrations before any code; (2) interface and system design covering the main window, menus, settings, forms, progress indicators, logs, and reports, with wireframes and navigation; (3) technology-stack selection; (4) backend implementation of core processing logic, configuration, data validation, file handling, error handling, logging, and authorized integrations; (5) testing and debugging of functions, interface interactions, error conditions, performance, and the whole application, with defect fixes and repeated tests; (6) build and release — packaging, dependency bundling, installation configuration, signing where appropriate, and verification on a clean Windows machine.

2. System Overview

Brute is a Windows desktop application with a native window shell. Its internal architecture follows the proposed maintainable layering: a user interface (window, forms, buttons, settings, reports), application services (input validation, task management, configuration and permissions), a core processing engine (the algorithms and business rules that perform the program's work), local storage (settings, records, and history), and an output system (logs, exports, and reports). This layering is a design proposal for the rebuild, not a verified diagram of any original Brute program.

Current actors:

• Security tester / operator — configures inputs and settings, starts and monitors test tasks via progress indicators and logs, and reviews results and reports.
• Application administrator / maintainer — manages application configuration, the local storage of settings and history, and authorized external-service integrations, and keeps the packaged Windows build working on clean machines.

Non-persona actors: authorized external services reached over REST APIs (provider-owned; Brute only communicates with services the operator/administrator has authorized), and the core processing engine and local storage as internal system processes.

Narrow exclusions and boundaries:

• External service integrations are limited to authorized services only.
• The architecture description, the technology candidate table (C#/.NET, WPF or WinUI, Python, SQLite, REST APIs, Git, MSIX or an installer tool), and the eight-step recreation plan are proposals, not confirmed details of any original Brute program; the stack is selected in Stage 3 based on the application's requirements.
• No cloud dependency is required; the product is local-first.

2a. Product Interpretation and Delivery Boundary

Brute is delivered as a first-party Windows desktop application with its own custom interface. The application owns its identity: because settings, records, and run history are durable and must remain bound to the correct operator across sessions, first use is established through self-service enrollment, and returning use is verified before any protected working surface opens. The anonymous entry surface explains what Brute is, who it is for, and what it does before any identity is established.

Working surfaces are protected: the Dashboard, New Test Run, Run Monitor, and Results belong to the security tester / operator; Settings and Integrations belong to the application administrator / maintainer; History is available to both signed-in roles. Identity and session continuity do not by themselves grant differentiated permissions beyond these accepted role boundaries.

All current work is in scope: requirements documentation, interface design, stack selection, backend implementation, testing, and Windows packaging/release. External services remain provider-owned and are only contacted when an administrator has configured them as authorized. Nothing in this document extends Brute into adjacent account-management, cloud, or unreviewed integration capabilities.

2c. Page Content and Component Coverage

The application shell is a persistent left rail (icons + labels, ink on cream) with a hot-magenta active indicator; on narrow viewports the rail collapses into a bottom tab bar. Every working surface carries the persistent rotated AUTHORIZED TARGET ONLY sticker badge (ink border, 6px offset shadow) as an ethical lock, not a dismissible banner.

Landing

• Information/state: anonymous public entry. Full-bleed split poster: cream left panel, solid hot-magenta right block bleeding off the right edge; oversized stacked Archivo Black headline "FIND THE WEAK PASSWORD BEFORE SOMEONE ELSE DOES" with the final line reversed out in cream on the magenta block; tangerine pill CTA "Start an authorized test"; ink monospace line "LOCAL-FIRST · WINDOWS · NO CLOUD REQUIRED"; rotated "AUTHORIZED TARGETS ONLY" sticker at the top-right of the magenta block; surreal oversized candy-pink key prop (flat 3D, ink outline) tilted -8deg and cropped by the magenta block's left edge.
• Primary actions: "Start an authorized test" routes an unauthenticated visitor to Sign Up; a secondary "Sign in" link routes returning users to Login.
• Supporting actions: none beyond navigation into identity surfaces.
• Domain entities: none persisted; static product description only.
• Component responsibilities: hero poster composition, wordmark (Archivo Black with tangerine underline and sticker dot), CTA pill, monospace trust line, sticker badge.
• States: loading — not applicable (static); empty — not applicable; success — poster renders fully at 375/768/1280 with all readable text and controls whole; error — not applicable; recovery — not applicable.

Login

• Information/state: anonymous returning-verification surface. Form with identity field and credential field; inline validation messages; a link to Sign Up for first-time users.
• Primary actions: submit credentials to verify identity and open the Dashboard (operator) or the administrator's default working surface.
• Supporting actions: navigate to Sign Up; return to Landing.
• Domain entities: user identity, session.
• Component responsibilities: form fields, validation display, submit pill button (magenta fill, cream text; hover flips to tangerine with ink text in 120ms), error banner.
• States: loading — submit button shows a busy state while verification runs; empty — fields blank with labels visible; success — redirect to the role's working surface; error — invalid credentials show an ink-bordered error panel with a retry path; recovery — fields remain populated (credential cleared) so the user can correct and resubmit.

Sign Up

• Information/state: anonymous self-service enrollment surface. Form for establishing a first identity with the fields needed to verify the same identity later; inline validation.
• Primary actions: create the identity and proceed to the protected application.
• Supporting actions: navigate to Login; return to Landing.
• Domain entities: user identity, role assignment (operator or administrator).
• Component responsibilities: form fields, validation display, submit pill button, success confirmation.
• States: loading — submit busy state; empty — blank form with labels; success — identity created and the user lands on the Dashboard; error — validation failures (missing or malformed fields, duplicate identity) shown inline with a correction path; recovery — entered values preserved for correction.

Dashboard

• Information/state: post-authentication hub for the security tester / operator. Summary of recent runs (name, target label, state, timestamp in muted warm grey), quick routes to New Test Run, Run Monitor, Results, and History. AUTHORIZED TARGET ONLY sticker present.
• Primary actions: start a new test run; open a recent run's monitor or results.
• Supporting actions: open History; sign out.
• Domain entities: test run (id, target, configuration summary, state, timestamps), run history records.
• Component responsibilities: colour-blocked stat chips (slight rotation), recent-run list rows (chunky rounded-rect), navigation rail.
• States: loading — skeleton rows in the recent-run list; empty — "No runs yet" panel with a CTA to New Test Run; success — populated recent runs; error — local store read failure shows an ink-bordered error panel with retry; recovery — retry re-reads local storage.

New Test Run

• Information/state: focused configuration surface for a test run. Forms for target identification, input format selection, and run settings; validation messages; the AUTHORIZED TARGET ONLY sticker.
• Primary actions: validate inputs and start the run, handing off to Run Monitor.
• Supporting actions: save the configuration as a draft; cancel back to Dashboard.
• Domain entities: test run configuration (target, input format, settings), validation result.
• Component responsibilities: form fields, input-format selector, validation summary, primary pill button, secondary cancel.
• States: loading — configuration defaults loading from local settings; empty — blank form with defaults applied; success — run created and Run Monitor opens; error — validation failures listed with field-level messages and no run started; recovery — correct fields and resubmit.

Run Monitor

• Information/state: owner of a running task. Live log marquee ticker at the top (monospace lines streaming right-to-left in an ink strip with a tangerine LIVE dot); hard-stepped progress bar; current run state (idle → running → complete) shown via colour-block wipes; surfaced processing and file-handling errors. AUTHORIZED TARGET ONLY sticker.
• Primary actions: start the task; stop/cancel a running task.
• Supporting actions: open Results when the run completes; return to Dashboard.
• Domain entities: test run, log line, progress state, error record.
• Component responsibilities: marquee ticker (static scrollable list under reduced motion), progress bar with stepped fill, state panel, error panel, action buttons.
• States: loading — run initializing with progress at zero; empty — no run selected shows a prompt to start one; success — completion state with a route to Results; error — processing or file-handling failure shown in an ink-bordered panel with the failing step and a retry/return path; recovery — retry restarts the task or returns to New Test Run with configuration preserved.

Results

• Information/state: completed-run findings rendered as a wall of sticker-like stat chips — each weak finding a rotated chip with thick ink border and hard offset shadow, tangerine for fail and lime for pass; run metadata in muted warm grey. AUTHORIZED TARGET ONLY sticker.
• Primary actions: generate and export a report; export logs.
• Supporting actions: return to Run Monitor or Dashboard; open History.
• Domain entities: result finding (target, outcome, timestamp), report, exported log file.
• Component responsibilities: stat-chip wall, export controls, report preview, file-save dialog handling.
• States: loading — chips pop in with slight overshoot (no overshoot under reduced motion); empty — no findings for the run shows a neutral panel; success — chips and export controls available; error — export or file-write failure shows an ink-bordered error panel with retry; recovery — retry export or choose a different destination.

History

• Information/state: independently revisitable browse surface for persisted records and run history across sessions, available to both signed-in roles. List of past runs with state, timestamps, and links to their Results.
• Primary actions: open a past run's Results.
• Supporting actions: filter or scan the list; return to Dashboard.
• Domain entities: run history record, result reference.
• Component responsibilities: history list rows, metadata labels, navigation rail.
• States: loading — skeleton rows; empty — "No history yet" panel; success — populated list; error — local store read failure with retry; recovery — retry re-reads local storage.

Settings

• Information/state: administrator-owned application configuration persisted locally: defaults for new runs, storage location, logging preferences. Form with validation.
• Primary actions: save configuration changes.
• Supporting actions: reset to defaults; return to Dashboard.
• Domain entities: application settings record.
• Component responsibilities: settings form, validation summary, save/reset buttons.
• States: loading — current settings read from local storage; empty — defaults shown on first use; success — saved confirmation; error — validation or write failure with an ink-bordered panel and retry; recovery — correct and resave.

Integrations

• Information/state: administrator-owned configuration of communication with authorized external services via REST APIs. List of configured services with authorization status; add/edit form for endpoint and credentials.
• Primary actions: add or update an authorized service configuration; test connectivity.
• Supporting actions: remove a configuration; return to Dashboard.
• Domain entities: integration configuration (service name, endpoint, authorization state).
• Component responsibilities: integration list, configuration form, status badges, test-connection control.
• States: loading — existing configurations read from local storage; empty — "No integrations configured" panel with an add CTA; success — saved configuration with status badge; error — connection test or save failure shown with the failing reason and retry; recovery — correct configuration and retest.

3. Functional Requirements

FR-1 — Document Brute before code. As a security tester / operator, I should have Brute's purpose, users, main features, input and output formats, supported operating systems, and integrations documented before any code is written, so that expected behavior is agreed first. (explicit)

• Lifecycle: initiator — operator/administrator reviews the documentation; result — a written behavior specification exists; failure — missing sections are identified and filled; continuation — design proceeds from the documented behavior.

FR-2 — Design the interface and navigation. As a security tester / operator, I should have the main window, menus, settings, forms, progress indicators, logs, and reports designed with wireframes and defined navigation, so that the working surfaces are coherent before implementation. (explicit)

• Lifecycle: initiator — operator/administrator reviews wireframes; result — wireframes and navigation defined; failure — gaps flagged and revised; continuation — implementation follows the design.

FR-3 — Select the technology stack. As an application administrator / maintainer, I should have a programming language, UI framework, database, and build system selected based on the application's requirements, so that the build is grounded in need rather than assumption. (explicit)

• Lifecycle: initiator — administrator selects; result — stack decision recorded; failure — unsuitable choice revisited; continuation — backend implementation begins.

FR-4 — Implement the backend. As an application administrator / maintainer, I should have core processing logic, a configuration system, data validation, file handling, error handling, logging, and authorized integrations implemented, so that the application performs its work reliably. (explicit)

• Lifecycle: initiator — administrator builds; result — backend modules operational; failure — errors surfaced in logs and handled; continuation — testing begins.

FR-5 — Test and debug. As an application administrator / maintainer, I should have individual functions, interface interactions, error conditions, performance, and the complete application tested, with defects fixed and tests repeated, so that the release is trustworthy. (explicit)

• Lifecycle: initiator — administrator runs tests; result — defects fixed and tests repeated; failure — failing cases recorded and retried; continuation — packaging proceeds.

FR-6 — Package and release for Windows. As an application administrator / maintainer, I should have the application packaged, dependencies bundled, installation configured, releases signed where appropriate, and verified to run on a clean Windows machine, so that operators can install and use it. (explicit)

• Lifecycle: initiator — administrator packages; result — installer verified on a clean Windows machine; failure — installation defects fixed and reverified; continuation — maintenance tracks bugs, versions, security updates, and new features.

FR-7 — Store settings, records, and history locally. As a security tester / operator, I should have my settings, records, and run history stored in local storage, so that my work persists across sessions without a cloud. (explicit)

• Lifecycle: initiator — operator's actions write records; result — data persisted locally and readable on return; failure — read/write errors surfaced with retry; continuation — History and Dashboard reflect persisted state.

FR-8 — Produce logs, exports, and reports. As a security tester / operator, I should be able to produce logs, exports, and reports from a completed run, so that findings can be shared and archived. (explicit)

• Lifecycle: initiator — operator requests export; result — report/log file written; failure — file-write error surfaced with retry; continuation — operator opens or shares the file.

FR-9 — Communicate with authorized external services via REST APIs. As an application administrator / maintainer, I should be able to configure communication with authorized external services over REST APIs, so that only approved services are contacted. (explicit)

• Lifecycle: initiator — administrator configures; result — configuration saved with authorization status; failure — connection test failure surfaced with reason; continuation — configuration available to the backend.

FR-10 — Self-service enrollment. As a security tester / operator, I should be able to establish my identity on first use through self-service enrollment, so that my settings, records, and history remain bound to me. (required_inference)

• Lifecycle: initiator — anonymous visitor on Landing; action — completes Sign Up; result — identity created and protected surfaces open; failure — validation errors shown inline with correction path; continuation — Dashboard.

FR-11 — Returning verification. As a security tester / operator, I should verify my identity on return before accessing protected working surfaces, so that durable local state stays bound to the correct person. (required_inference)

• Lifecycle: initiator — returning user on Login; action — submits credentials; result — session opened to the role's working surface; failure — invalid credentials with retry; continuation — Dashboard.

FR-12 — Administrator role for Settings and Integrations. As an application administrator / maintainer, I should have exclusive access to Settings and Integrations, so that configuration and authorized-service boundaries are controlled. (required_inference)

• Lifecycle: initiator — administrator; result — configuration changes saved; failure — validation errors with retry; continuation — backend uses updated configuration.

FR-13 — Initialize local storage. As an application administrator / maintainer, I should have local storage initialized for settings, records, and run history, so that the application has a durable foundation on first launch. (required_inference)

• Lifecycle: initiator — application on first launch; result — local store ready; failure — initialization error surfaced with retry; continuation — Dashboard and History read from the store.

4. User Personas

Security tester / operator

Product context. The operator is the primary daily user of Brute. They work inside the desktop application for extended sessions, running repeated credential tests against authorized targets and reading logs closely.

Primary goal. Complete a test run with clear logs and an exportable report of outcomes.

Distinct responsibilities. Configures inputs and run settings on New Test Run; starts and monitors tasks on Run Monitor via progress indicators and live logs; reviews findings on Results and exports reports and logs; browses past runs on History; sees recent runs on the Dashboard.

Inputs and decisions. Target identification, input format, and run settings; the decision to start, stop, or retry a run; the decision to export a report.

Interactions with other participants. Relies on the administrator's Settings defaults and authorized Integrations; the operator's runs and exports are the observable output the administrator's configuration supports.

Observable success. A run reaches completion with a readable log and an exported report; failures are surfaced with a clear recovery path.

Application administrator / maintainer

Product context. The administrator owns the desktop application's configuration, the local storage of settings and history, and the authorized external-service integrations, and keeps the packaged Windows build working on clean machines.

Primary goal. Keep configuration, logs, and releases consistent and the app running reliably.

Distinct responsibilities. Maintains Settings and Integrations; selects and validates the technology stack; implements and tests the backend; packages, signs where appropriate, and verifies releases on a clean Windows machine; tracks bugs, version changes, security updates, and new features.

Inputs and decisions. Configuration values, authorized-service endpoints and credentials, stack selection, release readiness.

Interactions with other participants. Provides the defaults and authorized-service boundaries the operator's runs depend on; receives the operator's run history as evidence of correct configuration.

Observable success. Configuration and logs remain consistent, integrations are limited to authorized services, and the packaged build runs on a clean Windows machine.

5. Core User Flows

Flow A — First use and enrollment (Security tester / operator).

1. The operator opens Brute and lands on Landing, which explains what Brute is, who it is for, and what it does.
2. The operator selects "Start an authorized test" and is routed to Sign Up.
3. The operator completes the enrollment form; validation errors are shown inline and corrected.
4. On success, the operator lands on Dashboard, which shows an empty recent-run state with a CTA to New Test Run.

Flow B — Returning verification (Security tester / operator).

1. The operator opens Brute and selects "Sign in" from Landing, arriving at Login.
2. The operator submits credentials; invalid credentials show an error panel and the operator retries.
3. On success, the operator lands on Dashboard.

Flow C — Configure and start a test run (Security tester / operator).

1. From Dashboard, the operator opens New Test Run.
2. The operator enters target identification, selects the input format, and sets run settings; validation messages appear for invalid fields and no run starts until they are corrected.
3. The operator starts the run and is handed off to Run Monitor.

Flow D — Monitor a run (Security tester / operator).

1. On Run Monitor, the operator watches the live log marquee ticker and the hard-stepped progress bar as the state moves idle → running.
2. If a processing or file-handling error occurs, an ink-bordered error panel shows the failing step; the operator retries or returns to New Test Run with configuration preserved.
3. On completion, the operator opens Results.

Flow E — Review and export results (Security tester / operator).

1. On Results, the operator reviews the sticker-chip wall of findings (tangerine for fail, lime for pass).
2. The operator generates and exports a report and exports logs; a file-write failure shows an error panel with retry.
3. The operator returns to Dashboard or opens History.

Flow F — Browse history (Security tester / operator).

1. The operator opens History from the rail.
2. The operator scans past runs and opens a past run's Results.

Flow G — Maintain configuration (Application administrator / maintainer).

1. The administrator signs in via Login and opens Settings.
2. The administrator updates defaults and logging preferences and saves; validation or write failures show an error panel with retry.
3. The administrator opens Integrations, adds or updates an authorized service configuration, and tests connectivity; failures show the reason and a retry path.

Flow H — Build, test, and release (Application administrator / maintainer).

1. The administrator documents Brute's behavior (FR-1) and reviews the interface design and wireframes (FR-2).
2. The administrator selects the stack (FR-3), implements the backend (FR-4), and runs tests, fixing defects and repeating (FR-5).
3. The administrator packages the application, bundles dependencies, configures installation, signs where appropriate, and verifies it runs on a clean Windows machine (FR-6).

6. Visuals Colors and Theme

Muse and headline. Jessica Walsh — Colour-saturated confidence for a security tool that refuses to whisper.

Mode. Light mode.

Colour tokens (exact hex by role).

• Background: #F4E9DC (warm cream)
• Surface: #FFF6EC (off-white panel)
• Text: #1A1416 (ink)
• Primary: #E6197C (hot magenta — primary action and identity)
• Accent: #FF5A1F (tangerine — alert/attack accent, weak-password findings, running states, wordmark underline)
• Muted: #7A6A62 (warm grey — metadata, timestamps, secondary labels)
• Pass/strong: #B8F04A (lime — reserved for pass/strong states in results)

Proportion. ~70% cream, 20% ink, 10% hot colour. Body text on cream and panels is always ink; magenta is used for filled buttons with cream text, never for body copy.

Typography.

• Headings: Archivo Black, single weight, tight tracking (-0.02em), all-caps or sentence case at huge sizes.
• Section headings: Syne 700 with wide tracking for labels.
• Body: Syne.
• Data and log lines: JetBrains Mono.
• Scale (1.5 modular): display 96px desktop / 56px mobile (clamp); h1 64/40; h2 40/28; h3 24/20; body 17/16; label 12 uppercase tracked; mono data 14/13. Landing hero headline uses clamp(56px, 8vw, 128px).

Shape language. Hard-edged colour blocks and thick 3px ink borders; sticker-like badges with a 6px offset ink shadow; pill buttons for primary actions; chunky rounded-rect log rows; slight rotations (-2deg / +1.5deg) on stickers and stat chips. No soft glass, no gradient blobs — flat colour fields with crisp edges.

Layout. Asymmetric editorial grid: 12-column base with deliberate 7/5 or 4/8 splits and colour-blocked panels bleeding to the viewport edge. Desktop app shell uses a persistent left rail (icons + labels, ink on cream) with a hot-magenta active indicator; the main working area is a stacked set of colour-blocked panels — Run Config, Live Log, Progress — each with its own ground colour. Mobile collapses the rail into a bottom tab bar; panels stack full-width.

Imagery. Surreal, art-directed props rendered in flat 3D: an oversized key made of candy-coloured plastic, a padlock with a cheeky face, a melting padlock sticker, colour-blocked abstract shapes. No stock photography of hooded hackers. Diagrams and progress visuals are chunky flat vector shapes with ink outlines. The "Brute" wordmark is set in Archivo Black with a tangerine underline and a small sticker dot.

Avoid. Blue/indigo primaries on white; gradient-blob heroes or glassmorphism; uniform hover-lift card grids; hooded-hacker stock photos, matrix rain, padlock clip art; muted corporate greys and trust-blue enterprise styling; Inter, Roboto, Arial, Helvetica, Poppins, or system-ui for headings or body; continuous ambient animation; soft pastel palettes.

Readability rule. Readable text and controls stay whole at 375px, 768px, and 1280px, wrapping or scaling to fit; imagery and decoration may be cropped, bled, rotated, or overlapped as directed, but never over readable text or controls.

7. Signature Design Concept

The Operator's Poster. The public entry is a full-bleed split poster, not a centred SaaS hero. A solid hot-magenta (#E6197C) colour block occupies the right 45% of the viewport from top to bottom, bleeding off the right edge; the left 55% is cream (#F4E9DC) carrying an oversized stacked Archivo Black headline — "FIND THE WEAK PASSWORD BEFORE SOMEONE ELSE DOES" — set at clamp(56px, 8vw, 128px), left-aligned, with the last line reversed out in cream on the magenta block. Beneath the headline sits a tangerine pill CTA ("Start an authorized test") and a small ink monospace line "LOCAL-FIRST · WINDOWS · NO CLOUD REQUIRED". A surreal oversized candy-pink key prop (flat 3D, ink outline) is cropped by the magenta block's left edge, tilted -8deg, overlapping the colour boundary. A rotated sticker badge "AUTHORIZED TARGETS ONLY" sits at the top-right of the magenta block. No gradient, no centred stack, no blue button. The same sticker badge persists on every working surface as an ethical lock.

8. Interaction Model & Motion Direction

Interaction Model: Animated Motion Tempo: expressive Hero Dimensionality: layered_2d

Landing Hero Motion Brief.

• Focal subject: the oversized candy-pink key prop (flat 3D, ink outline) tilted -8deg, cropped by the magenta block's left edge.
• Input → transformation → outcome thesis: on load, the magenta block wipes in from the right edge and the stacked headline settles line by line; the key prop pops in with a slight overshoot and the sticker badge rotates into place — outcome: a composed poster where the CTA is immediately visible and the ethical lock is unmistakable.
• Motion vocabulary: colour-block wipes, sticker pop-in with slight overshoot, hover colour flips (magenta ↔ tangerine, 120ms hard swap), hard stepped progress fills.
• Composed first frame: cream left / magenta right split, headline fully readable, CTA pill and monospace trust line beneath, key prop overlapping the colour boundary, sticker badge top-right.
• Reduced-motion state: no overshoot and no marquee; the poster renders in its final composed state; live log lines wrap into a static scrollable list.

9. Non-Functional Requirements

• NFR-1 — Windows desktop target. The product targets Windows desktop; releases must be verified to run on a clean Windows machine. (explicit)
• NFR-2 — Authorized services only. External service integrations are limited to authorized services. (explicit)
• NFR-3 — Proposals are not confirmed details. The proposed architecture, technology table, and recreation plan are proposals, not confirmed details of any original Brute program; the stack is selected in Stage 3 from the application's requirements. (explicit)
• NFR-4 — Local-first. Settings, records, and history are stored locally; no cloud is required. (explicit)
• NFR-5 — Readable at every viewport. Readable text and controls stay whole at 375px, 768px, and 1280px. (explicit, from creative direction)
• NFR-6 — Reduced motion. prefers-reduced-motion removes overshoot and marquee and provides a usable static arrangement. (explicit, from creative direction)
• NFR-7 — Logging and error handling. The backend surfaces processing and file-handling errors in logs and in the interface with a recovery path. (explicit)

10. Tech Stack

Source candidates (proposals, not confirmed details of any original Brute program): C# and .NET for the Windows desktop application and business logic; WPF or WinUI for the native Windows user interface; Python for processing logic, automation, and prototypes; SQLite for the local database and application history; REST APIs for communication with authorized external services; Git for source control and development history; MSIX or an installer tool for Windows application distribution.

The stack is selected in Stage 3 based on the application's requirements. The proposed internal architecture layers the user interface, application services, core processing engine, local storage, and output system as described in Section 2.

11. Assumptions and Constraints

• A-1. The architecture description, technology table, and recreation plan are proposals; the final stack is chosen in Stage 3. (explicit)
• A-2. External integrations are limited to authorized services; no unauthorized service is contacted. (explicit)
• A-3. Releases are verified on a clean Windows machine. (explicit)
• A-4. Identity is application-owned because durable local settings, records, and run history must remain bound to the correct operator across sessions. (required_inference)
• A-5. Settings and Integrations are administrator-only; Dashboard, New Test Run, Run Monitor, and Results are operator surfaces; History is available to both signed-in roles. (required_inference)
• A-6. Local storage is initialized on first launch for settings, records, and run history. (required_inference)

12. Glossary

• Brute — the Windows desktop cybersecurity / password-testing tool built under the lifestyle-cybersecurity project.
• Test run — a configured, started, and monitored credential test against an authorized target.
• Authorized target — a system the operator is permitted to test; enforced by the persistent AUTHORIZED TARGET ONLY sticker and the authorized-services constraint.
• Authorized external service — a REST-API service the administrator has explicitly configured as permitted.
• Run history — persisted records of past runs stored locally.
• Sticker chip — a rotated, ink-bordered result badge with a hard offset shadow; tangerine for fail, lime for pass.
• AUTHORIZED TARGET ONLY sticker — the persistent rotated ethical-lock badge on every working surface.
• Hard stepped fill — a progress bar that fills in discrete segments rather than a smooth gradient.