diff --git a/nix/modules/home/commands.nix b/nix/modules/home/commands.nix new file mode 100644 index 0000000..6f1b8bf --- /dev/null +++ b/nix/modules/home/commands.nix @@ -0,0 +1,815 @@ +{ config, pkgs, lib, ... }: + +let + # ── /catchup ────────────────────────────────────────────────────── + catchupCommand = '' + --- + description: Catch up on project context and recent git history + --- + + Read all available project context files and recent git history, then + produce a concise status summary. Do NOT modify any files. + + ## Steps + + 1. Read any `.ignore/` context files that exist at the project root + (skip missing files without error): + - `.ignore/CONTEXT.md` + - `.ignore/DECISIONS.md` + - `.ignore/TODO.md` + - `.ignore/FIXME.md` + - `.ignore/SCRATCH.md` + + 2. Run the following read-only git commands _in parallel_ (they are + independent and safe to batch): + - `git log --oneline --all --graph -30` (branch topology) + - `git log --format='%h %s (%cr)' -10` (recent commits with + relative dates) + - `git status --short` (working tree state) + - `git diff --stat HEAD~5..HEAD` (diffstat of recent commits) + - `git diff` (uncommitted changes) + - `git branch -a` (all branches) + + 3. If the project has CI configuration (`.woodpecker.yml`, + `.github/workflows/`, `.forgejo/workflows/`, etc.), note the CI + system in use and any recent build status if visible from the repo. + + 4. Produce a structured summary with these sections: + + **Project Overview** -- what this project is and its high-level + architecture (from CONTEXT.md, or infer from the repo if absent). + + **Recent Activity** -- last ~10 commits with relative dates, + grouped by theme if possible. Note the current branch. + + **Branch Status** -- list any branches other than `main`/`master`, + note which are ahead/behind, flag any that look stale (no commits + in >2 weeks). Omit this section if only one branch exists. + + **Uncommitted Changes** -- summarize any staged or unstaged + modifications in the working tree. + + **Open TODOs** -- highlights from TODO.md, grouped by priority. + + **Known Issues** -- highlights from FIXME.md. + + **Recent Decisions** -- notable entries from DECISIONS.md. + + Omit any section whose source file is missing or empty. + Use tables where they improve readability. + Keep the summary concise -- aim for quick orientation, not + exhaustive detail. + ''; + + # ── /context-update ────────────────────────────────────────────── + contextUpdateCommand = '' + --- + description: Update all .ignore/ context files with current project state + --- + + Analyze the current state of the project and update the `.ignore/` + context files. You may create or modify any file in `.ignore/`. + + ## Steps + + 1. If `.ignore/` does not exist at the project root, create it. + + 2. Read all existing `.ignore/` files: + - `CONTEXT.md` -- project overview and architecture + - `TODO.md` -- tasks and follow-ups + - `FIXME.md` -- known issues and technical debt + - `DECISIONS.md` -- architecture decisions and rationale + - `SCRATCH.md` -- temporary notes (read-only, do not modify) + + 3. Gather context: + - Scan the project directory structure (top two levels) + - Read key configuration files (Cargo.toml, package.json, + flake.nix, etc. -- whatever applies) + - Detect if the project targets Wasm (look for + `wasm32-unknown-unknown` in `.cargo/config.toml`, `wasm-pack` + in dependencies, `[lib] crate-type = ["cdylib"]`, etc.) + - Run these git commands in parallel: + - `git log --format='%h %s (%cr)' -20` + - `git branch -a` + - `git remote -v` + - `git status --short` + - `git diff --stat HEAD~10..HEAD` + + 4. Scan source code for inline markers and cross-reference against + `.ignore/` tracking files: + - Search for `TODO`, `FIXME`, `HACK`, `XXX` comments in source + - Note any that are _not_ tracked in `TODO.md` or `FIXME.md` + - Note any tracked items that no longer appear in source (may + have been resolved without updating the tracking files) + + 5. Update `.ignore/CONTEXT.md` with these sections: + + ```markdown + # Project Context + + **Generated:** YYYY-MM-DDTHH:MM:SSZ + **Updated:** YYYY-MM-DD + + ## Overview + + + ## Architecture + + + ## Directory Structure + + + ## Key Patterns + + + ## Hosts / Targets / Environments + + + ## Active Development + + + ## Dependencies & Tooling + + ``` + + Adapt sections to the project -- omit sections that don't apply, + add sections that do. Preserve any manually-written sections from + the previous version that are still relevant. + + Always update the `**Updated:**` line to today's date. + + 6. Audit and update `.ignore/TODO.md`: + - Mark tasks as `[x]` if the codebase shows they've been completed + - Mark tasks as `[>]` if they appear deferred or stale + - Add `[?]` to tasks that are ambiguous or need clarification + - Remove tasks that are clearly obsolete (the item no longer + makes sense given the current state of the project) + - Add any new tasks discovered during the analysis (including + inline `TODO` comments found in step 4) + - Keep the priority grouping (high/medium/low) if present + - Update the `**Updated:**` line + + 7. Audit and update `.ignore/FIXME.md`: + - Remove issues that have been fixed (verify in the codebase) + - Update descriptions if the nature of an issue has changed + - Add any new issues discovered during the analysis (including + inline `FIXME` comments found in step 4) + - Note if a workaround has been applied but the root cause remains + - Update the `**Updated:**` line + + 8. Audit and update `.ignore/DECISIONS.md`: + - Add any new architectural decisions evident from recent commits + - Create a new ADR entry when: a new technology/pattern was + adopted, a previous approach was replaced, a non-obvious + trade-off was made, or a significant configuration choice was + introduced. Do _not_ create entries for routine changes. + - Note if a previous decision has been reversed or superseded + (add a `**Superseded by:** ADR-NNN` annotation) + - Preserve existing entries -- do not remove decisions, only + annotate them if they've been revisited + - Update the `**Updated:**` line + + 9. Leave `.ignore/SCRATCH.md` alone -- that file is for temporary + notes managed by the user. + + 10. Use checkbox notation for task tracking: + + | Notation | Meaning | + |----------|---------------------| + | `[ ]` | Not started | + | `[x]` | Complete | + | `[-]` | In progress | + | `[>]` | Deferred | + | `[?]` | Needs clarification | + + 11. Print a brief summary of all changes made across the `.ignore/` + files, including: + - What was updated in CONTEXT.md + - How many TODOs were completed/added/removed + - How many FIXMEs were resolved/added + - Any new decisions recorded + - Any inline markers found in source that weren't being tracked + ''; + + # ── /qa ─────────────────────────────────────────────────────────── + qaCommand = '' + --- + description: QA the current project -- build examples, test edges, evaluate ergonomics + --- + + Act as a thorough QA department for this project. Your goal is to + evaluate the project from an outsider's perspective -- someone trying + to use this library, API, or application for the first time. + + Be exhaustive. Try to break things. Be honest about what works and + what doesn't. + + ## Steps + + ### 1. Understand the project + + - Read `.ignore/CONTEXT.md` if it exists + - Read the README and any existing documentation + - Scan the public API surface (exported types, functions, traits, + modules) + - Read existing examples in `examples/` or `tests/` if present + - Identify the project type: library, CLI tool, application, Wasm + bindings, protocol implementation, etc. + - Determine the appropriate language for example apps: + - Rust library -> Rust examples + - Wasm bindings -> JavaScript/TypeScript examples + - CLI tool -> shell scripts that exercise it + - HTTP API -> curl scripts or a small client + - Use your judgement based on the target audience + + ### 2. Create the QA workspace + + - Create `.ignore/qa/` if it doesn't exist + - Create a timestamped session directory: + `.ignore/qa/YYYY-MM-DDTHH-MM/` + - Create `examples/` within the session directory + + ### 3. Write example apps + + Write small, realistic, buildable programs in the session's + `examples/` directory that exercise the project from a user's + perspective. Each example should be a complete project that can + actually be compiled and run (include Cargo.toml, package.json, etc. + as appropriate). + + Create at least these categories: + + **`basic_usage/`** -- The simplest possible "hello world" for this + API. What would someone copy-paste from the README? Does it work? + + **`real_world/`** -- A small but realistic use case. Something + someone might actually build with this library. Exercise the main + happy path end-to-end. + + **`error_handling/`** -- Deliberately trigger every error path you + can find. Pass invalid inputs, violate preconditions, exhaust + resources. Evaluate: + - Are errors typed or stringly? + - Do error messages explain what went wrong and how to fix it? + - Can you recover from errors gracefully? + - Are errors documented? + + **`edge_cases/`** -- Boundary conditions and unusual inputs: + - Empty collections, zero-length inputs + - Maximum values, overflow conditions + - Unicode, special characters, very long strings + - Concurrent usage (if applicable) + - Null/None/missing optional values + - Re-entrancy, double-initialization + - Resource cleanup (Drop, close, cleanup) + + **`misuse/`** -- Deliberately try to misuse the API: + - Can you construct invalid states? + - What happens if you call methods in the wrong order? + - Does the type system prevent misuse at compile time? + - Are there runtime panics that could be compile-time errors? + - Are there opportunities for phantom types or witness values + ("Ghosts of Departed Proofs") to make invalid states + unrepresentable? + - Does the API follow "Parse, Don't Validate"? Are there places + where a validated newtype would prevent downstream misuse? + + ### 4. Build and run every example + + - Actually compile/build each example + - Run each example and capture output + - Record all compiler errors, warnings, runtime panics, unexpected + behavior + - Pay attention to: + - Quality of compiler error messages when you misuse the API + - Quality of runtime error messages + - Whether panics occur in normal or edge-case usage + - Performance surprises (unexpectedly slow operations) + + ### 5. Static analysis + + Run available linting and analysis tools: + + - `cargo clippy -- -W clippy::pedantic` (for Rust projects): + evaluate which warnings are _meaningful_ vs noise. Report + significant findings, ignore style-only pedantic lints that + don't indicate real issues. + - Language-equivalent linters for non-Rust projects. + - Record output; don't just dump it -- curate the findings. + + ### 6. Evaluate ergonomics + + Assess the developer experience from an outsider's perspective: + + **Imports and discoverability:** + - Can you figure out what to import? + - Are re-exports sensible? Too many? Too few? + - Is the module structure intuitive? + + **Naming:** + - Are types, functions, and methods named clearly? + - Is naming consistent across the API? + - Would a new user guess the right name? + + **Type design:** + - Does the type system prevent misuse? (Parse, Don't Validate) + - Are invalid states representable? + - Are newtypes used for domain concepts? + - Are generic bounds reasonable? + - Are there phantom-type opportunities being missed? + + **Error types:** + - Are errors informative? + - Do they implement std::error::Error properly? + - Is the error hierarchy sensible? + - Can you match on specific error variants? + + **Documentation:** + - Are public items documented? + - Do doc comments include examples? + - Is there module-level documentation explaining concepts? + - Are there gaps between the docs and actual behavior? + + **Overall feel:** + - How many lines of code does it take to do something basic? + - Are there unnecessary ceremony or boilerplate requirements? + - Does the API guide you toward correct usage? + - What would you change if you were designing this API? + + ### 7. Conditional: Wasm targets + + If the project targets `wasm32-unknown-unknown` or has Wasm bindings: + + - Build for the Wasm target (`cargo build --target wasm32-unknown-unknown` + or `wasm-pack build`) + - Run Wasm-specific tests (`wasm-pack test --node` / `--headless`) + - Check for host-dependent code paths (`std::fs`, `std::net`, + `std::time::Instant`, `std::thread`, etc.) that will fail or + behave differently under Wasm + - Verify that `#[wasm_bindgen]` exports have sensible JS-facing + types and names + - Note any `cfg(target_arch = "wasm32")` conditionals and whether + they're tested + + Skip this section entirely if the project does not target Wasm. + + ### 8. Conditional: `no_std` compatibility + + If the project is a library crate and its `Cargo.toml` contains + `#![no_std]` or a `no_std`/`std` feature flag: + + - Verify the crate actually compiles with `--no-default-features` + (or with only the `no_std`-compatible feature set) + - Check for accidental `std`-only API usage behind feature gates + - Verify that `alloc` vs `std` feature gating is correct + - Note any public API items that are unavailable under `no_std` + and whether this is documented + + Skip this section entirely if the project is not a `no_std` library. + + ### 9. Check for obvious missing tests + + Review the existing test suite and flag gaps. Do NOT write tests -- + just identify what's missing: + + - Untested public functions or methods + - Missing edge case coverage + - No error path tests + - Missing property-based tests for functions with clear invariants + (serialization roundtrips, parsers, etc.) + - Missing integration or end-to-end tests + - Insufficient concurrency testing (if applicable) + + ### 10. Write the QA reports + + Write structured markdown reports in the session directory: + + **`REPORT.md`** -- Main summary: + + ```markdown + # QA Report + > Project: + > Date: YYYY-MM-DD HH:MM + > Scope: Full project QA + + ## Summary + + + ## Findings by Severity + + | Severity | Count | + |----------|-------| + | [CRITICAL] | N | + | [WARNING] | N | + | [INFO] | N | + | [GOOD] | N | + + ## Top Issues + + + ## API Ergonomics + + + ## Error Handling + + + ## Type Safety + + + ## Documentation Gaps + + + ## Missing Test Coverage + + + ## Positive Observations + + + ## Recommendations + + ``` + + **`ERGONOMICS.md`** -- Detailed ergonomics feedback with code + examples showing what's awkward and what's good. Use before/after + comparisons where appropriate. + + **`EDGE-CASES.md`** -- Each edge case tested, what input was used, + what happened, what was expected, and severity: + + ```markdown + ### [WARNING] Empty input causes panic in parse() + + **Input:** `parse("")` + **Expected:** Returns `Err(ParseError::Empty)` + **Actual:** `panic!("index out of bounds")` + **Location:** src/parser.rs:42 + ``` + + **`MISSING-TESTS.md`** -- List of test gaps with brief rationale for + why each test should exist. + + **`COMPILATION-WARNINGS.md`** -- Curated compiler and linter + warnings with assessment of which are meaningful, which are noise, + and which indicate latent bugs. Only create this file if there are + warnings worth recording. + + ### Severity labels + + Use text-based severity labels: + + | Label | Meaning | + |-------|---------| + | `[CRITICAL]` | Incorrect behavior, data loss, panic in normal use | + | `[WARNING]` | Confusing API, poor error messages, footgun | + | `[INFO]` | Minor ergonomic issue, documentation gap | + | `[GOOD]` | Positive observation, good design choice | + + ### 11. Print a summary to the chat + + After writing all reports, print a concise summary: + - Number of issues by severity + - Top 3 most important findings + - Overall assessment (1-2 sentences) + - Path to the full reports + ''; + + # ── /red-team ───────────────────────────────────────────────────── + redTeamCommand = '' + --- + description: Red-team the current project -- adversarial security and robustness analysis + --- + + Act as an expert red team performing a thorough adversarial analysis + of this project. Your goal is to _break things_ -- find + vulnerabilities, logic errors, unsound abstractions, and failure + modes that normal testing and QA would miss. + + Be creative. Think like an attacker. Assume the worst about inputs, + environments, and dependencies. + + For library projects, you will also act as a separate "builder team" + that writes realistic applications using the library, then switch + hats and try to break those applications through the library's + weaknesses. + + ## Phases + + ### 1. Reconnaissance + + - Read `.ignore/CONTEXT.md` if it exists + - Read the README, documentation, and public API surface + - Identify the project type: library, CLI, service, Wasm bindings, + protocol implementation, etc. + - Map the attack surface: + - All entry points (public API, CLI args, network listeners, + file parsers, deserialization boundaries, FFI) + - Trust boundaries (where does untrusted input enter? where do + privilege levels change?) + - `unsafe` code blocks and their stated invariants + - Cryptographic operations (signing, encryption, hashing, RNG) + - Concurrency primitives (locks, channels, atomics, async tasks) + - Resource management (file handles, connections, memory + allocation patterns) + - External dependencies with broad capabilities + + ### 2. Threat model + + Produce a structured threat model. Use STRIDE as a starting + framework, adapted to what's relevant for this project: + + - **Spoofing** -- Can identities or origins be faked? + - **Tampering** -- Can data be modified in transit or at rest? + - **Repudiation** -- Can actions be denied? Is there an audit trail? + - **Information disclosure** -- Can secrets leak through errors, + logs, timing, or memory? + - **Denial of service** -- Can the system be made unavailable or + degraded? + - **Elevation of privilege** -- Can an actor gain capabilities + they shouldn't have? + + Include an ASCII trust-boundary diagram showing where data flows + cross trust domains. + + Skip categories that genuinely don't apply (e.g., repudiation for + a pure data structure library), but explain _why_ they don't apply. + + ### 3. Builder team (libraries and frameworks) + + If the project is a library, framework, or reusable component: + + Create `.ignore/red-team/YYYY-MM-DDTHH-MM/apps/` and write 3-4 + realistic, _buildable_ applications that consume the library. Each + must be a complete project (Cargo.toml / package.json / etc.): + + **`naive_consumer/`** -- A first-time user who reads the docs, + trusts the API, and does the obvious thing. No defensive coding. + This is the "happy path with no guardrails" baseline. + + **`production_app/`** -- A more careful application with error + handling, input validation, logging, and defensive coding. This + represents what a competent user _should_ write. + + **`adversarial_input/`** -- An application that receives untrusted + external input (from a file, network, or user) and passes it + through the library. This is the primary attack target. + + **`concurrent_usage/`** -- An application exercising the library + from multiple threads or async tasks simultaneously. Include + shared state, contention, and high-throughput scenarios. Skip if + the library is explicitly single-threaded. + + Build and verify each application compiles and runs on the happy + path before proceeding to attacks. + + For non-library projects (CLIs, services, protocols), generate + shell scripts, test harnesses, or client simulators instead. + + ### 4. Red team attacks + + Systematically attack the project across these categories. For each + category, describe what you tried, what you expected, and what + actually happened. Write PoC exploit code in + `.ignore/red-team/YYYY-MM-DDTHH-MM/exploits/` for anything that + breaks. + + #### 4a. Malformed and adversarial inputs + + - Boundary values: empty, zero-length, maximum size, off-by-one + - Type confusion: wrong types at serialization boundaries + - Encoding attacks: invalid UTF-8, overlong encodings, null bytes + in strings, mixed encodings + - Injection: if any string is interpolated into commands, queries, + or structured formats + - Extremely large inputs: can you trigger OOM or quadratic behavior? + - Nested/recursive structures: can you blow the stack? + + #### 4b. State machine violations + + - Call methods in the wrong order + - Re-initialize after finalization + - Use after close/drop/shutdown + - Double-initialize, double-close + - Interleave operations that assume exclusive access + + #### 4c. Resource exhaustion + + - Memory: construct inputs that cause unbounded allocation + - CPU: find algorithmic complexity attacks (hash flooding, + regex backtracking, quadratic string operations) + - File descriptors: open without closing in error paths + - Disk: unbounded logging or temp file creation + - Threads/tasks: fork bomb via recursive spawning + + #### 4d. Concurrency attacks + + - Data races: shared mutable state without synchronization + - Deadlocks: lock ordering violations, async deadlocks + - TOCTOU: time-of-check to time-of-use gaps + - Priority inversion in task scheduling + - Starvation: can one actor monopolize a shared resource? + + #### 4e. Unsafe code audit + + - Examine every `unsafe` block (or equivalent in non-Rust: raw + pointers in C/C++, `unsafePerformIO` in Haskell, etc.) + - Verify the stated safety invariants actually hold + - Check for: aliased mutable references, use-after-free, + uninitialized memory, incorrect `Send`/`Sync` implementations, + unsound lifetime extensions + - Can safe code trigger UB through the public API? + + #### 4f. Cryptographic review + + - Algorithm choice: are algorithms current and appropriate? + - Randomness: is the RNG cryptographically secure? Properly seeded? + - Timing side-channels: are comparisons constant-time? + - Nonce/IV reuse: can the same nonce be used twice? + - Key management: are keys zeroed after use? Exposed in logs/errors? + - Signature malleability: can valid signatures be transformed? + + Skip if the project has no cryptographic operations. + + #### 4g. Type system escape hatches + + - Can you construct values that violate type invariants via + `mem::transmute`, pointer casts, `as` conversions, or + deserialization? + - Are there `From`/`Into` implementations that bypass validation? + - Can you create invalid enum discriminants? + - Are newtype invariants enforced or just conventional? + - Can `Default` produce invalid instances? + + #### 4h. Deserialization attacks + + - Malformed payloads: truncated, extra fields, wrong types + - Version confusion: old format vs new code, new format vs old code + - Billion-laughs / zip bomb style expansion + - Confused deputy: deserialize into a type that grants capabilities + - Schema evolution: are unknown fields rejected or silently dropped? + + Skip if the project has no serialization/deserialization. + + #### 4i. Supply chain + + - Check dependency tree for known vulnerabilities + - Identify unmaintained dependencies (no commits in >1 year, + archived repos) + - Look for typosquatting risks in dependency names + - Check that `Cargo.lock` / lockfiles are committed + - Verify build reproducibility if claimed + - Check for `build.rs` scripts that download or execute external + code + + #### 4j. Network and protocol attacks + + - Packet fuzzing: malformed messages at protocol boundaries + - Protocol state machine: send messages in wrong order, replay + old messages, inject messages mid-handshake + - TLS/transport: downgrade attacks, certificate validation + - Amplification: can a small request cause a large response? + - Connection exhaustion: slowloris, half-open connections + - Replay attacks: can captured messages be replayed? + + Skip if the project has no network communication. + + ### 5. Automated tooling + + Run whatever security tooling is available. Record output even if + a tool isn't installed (note what _would_ be useful to run). + + - `cargo audit` / `npm audit` / language-equivalent dependency + scanner + - `cargo clippy -- -W clippy::pedantic -W clippy::undocumented_unsafe_blocks` + - `cargo +nightly miri test` for unsafe code (if Rust, if feasible) + - `cargo geiger` for unsafe dependency audit (if available) + - Any project-specific security checks (e.g., `wasm-pack test`, + sanitizers) + + ### 6. Build and run everything + + - Compile all builder-team apps and exploit PoCs + - Run each exploit and record: did it succeed? what was the impact? + - Capture panics, error messages, undefined behavior indicators + - Run Miri on exploits if feasible (Rust + unsafe code) + - For each confirmed vulnerability, assess real-world exploitability + + ### 7. Reports + + Write all output to `.ignore/red-team/YYYY-MM-DDTHH-MM/`: + + **`REPORT.md`** -- Executive summary: + + ```markdown + # Red Team Report + > Project: + > Date: YYYY-MM-DD HH:MM + > Scope: Full adversarial analysis + + ## Risk Assessment + + + ## Findings by Severity + + | Severity | Count | + |----------|-------| + | [CRITICAL] | N | + | [WARNING] | N | + | [INFO] | N | + | [GOOD] | N | + + ## Top Findings + + + ## Attack Surface Summary + + + ## Confirmed Vulnerabilities + + + ## Failed Attacks + + + ## Positive Observations + + + ## Recommendations + + ``` + + **`THREAT-MODEL.md`** -- Full threat model with: + - Attack surface diagram (ASCII) + - Trust boundaries + - Threat categories with likelihood and impact assessment + - Data flow analysis + + **`VULNERABILITIES.md`** -- Each confirmed vulnerability: + + ```markdown + ### [CRITICAL] Buffer overread via crafted input + + **Category:** Malformed input / unsafe code + **Location:** src/parser.rs:142 + **Description:** ... + **Reproduction:** See `exploits/buffer_overread/` + **Impact:** Memory disclosure, potential code execution + **Suggested fix:** ... + ``` + + **`ATTACK-LOG.md`** -- Every attack attempted, including failures: + + ```markdown + ### [GOOD] State machine violation -- held up + + **Category:** State machine + **Attack:** Called `finalize()` then `update()` on a committed builder + **Expected:** Panic or undefined behavior + **Actual:** Returned `Err(BuilderError::AlreadyFinalized)` -- correct + **Notes:** Type-state pattern prevents misuse at compile time + ``` + + **`DEPENDENCY-AUDIT.md`** -- Dependency analysis: + - Known CVEs with severity and affected versions + - Unmaintained or archived dependencies + - Dependencies with excessive permissions or capabilities + - Version pinning assessment + - Supply chain observations + + **`apps/`** -- Builder team's applications (if created) + + **`exploits/`** -- PoC code for confirmed vulnerabilities + + ### Severity labels + + Use text-based severity labels consistent with other commands: + + | Label | Meaning | + |-------|---------| + | `[CRITICAL]` | Exploitable vulnerability, data loss, UB, unsoundness | + | `[WARNING]` | Potential vulnerability, unsafe pattern, unverified invariant | + | `[INFO]` | Minor concern, hardening opportunity, defense-in-depth gap | + | `[GOOD]` | Attack was attempted and the code correctly defended against it | + + ### 8. Print a summary to the chat + + After writing all reports, print a concise summary: + - Overall risk assessment (1-2 sentences) + - Severity counts table + - Top 5 findings with one-line descriptions + - Number of attacks attempted vs confirmed vulnerabilities + - Path to the full reports + ''; + +in +{ + # Commands -- deployed to both Claude Code and OpenCode + home.file.".claude/commands/catchup.md".text = catchupCommand; + home.file.".claude/commands/context-update.md".text = contextUpdateCommand; + home.file.".claude/commands/qa.md".text = qaCommand; + home.file.".claude/commands/red-team.md".text = redTeamCommand; + + xdg.configFile."opencode/commands/catchup.md".text = catchupCommand; + xdg.configFile."opencode/commands/context-update.md".text = contextUpdateCommand; + xdg.configFile."opencode/commands/qa.md".text = qaCommand; + xdg.configFile."opencode/commands/red-team.md".text = redTeamCommand; +} diff --git a/nix/modules/home/default.nix b/nix/modules/home/default.nix index bed49f8..de53eeb 100755 --- a/nix/modules/home/default.nix +++ b/nix/modules/home/default.nix @@ -6,6 +6,7 @@ in { imports = [ ./agents.nix + ./commands.nix ./doom.nix ./packages.nix ./programs.nix diff --git a/nix/modules/home/hosts/wisteria.nix b/nix/modules/home/hosts/wisteria.nix index 68c50df..304ba67 100755 --- a/nix/modules/home/hosts/wisteria.nix +++ b/nix/modules/home/hosts/wisteria.nix @@ -493,6 +493,25 @@ in { xdg.configFile."cava/config".force = true; + # Quickshell mountain-wave audio visualizer (systemd user service) + # Runs as a separate quickshell instance on the Wayland bottom layer. + # Spawns its own cava process internally for audio data. + systemd.user.services.quickshell-visualizer = { + Unit = { + Description = "Quickshell mountain-wave audio visualizer"; + After = [ "graphical-session.target" ]; + PartOf = [ "graphical-session.target" ]; + }; + Service = { + ExecStart = "${pkgs.quickshell}/bin/quickshell -p %h/.config/quickshell-visualizer"; + Restart = "on-failure"; + RestartSec = 3; + }; + Install = { + WantedBy = [ "graphical-session.target" ]; + }; + }; + # Quickshell mountain-wave audio visualizer (bottom layer, Catppuccin Mocha) xdg.configFile."quickshell-visualizer/shell.qml".text = '' import Quickshell @@ -696,7 +715,6 @@ in { "exec-once" = [ "${pkgs.polkit_gnome}/libexec/polkit-gnome-authentication-agent-1" - "quickshell -p ~/.config/quickshell-visualizer" "wl-paste --type text --watch cliphist store" "wl-paste --type image --watch cliphist store" "ghostty --class=com.expede.special-left"