lilrae 8.0.0__tar.gz

lilrae-8.0.0/.bestpractices.json

@@ -0,0 +1,93 @@
+{
+  "name": "APTL — Advanced Purple Team Lab",
+  "description": "A local Docker-based purple-team lab for exercising human and AI red- and blue-team workflows in an intentionally vulnerable enterprise range.",
+  "homepage_url": "https://openrae.github.io/lilrae/",
+  "repo_url": "https://github.com/OpenRAE/lilrae",
+  "license": "MIT",
+  "description_good_status": "Met",
+  "description_good_justification": "https://openrae.github.io/lilrae/",
+  "interact_status": "Met",
+  "interact_justification": "https://openrae.github.io/lilrae/#help-and-project-policies",
+  "contribution_status": "Met",
+  "contribution_justification": "https://github.com/OpenRAE/lilrae/blob/main/CONTRIBUTING.md",
+  "contribution_requirements_status": "Met",
+  "contribution_requirements_justification": "https://github.com/OpenRAE/lilrae/blob/main/CONTRIBUTING.md#making-changes",
+  "floss_license_status": "Met",
+  "floss_license_justification": "APTL is distributed under the OSI-approved MIT License.",
+  "floss_license_osi_status": "Met",
+  "floss_license_osi_justification": "The MIT License is OSI approved.",
+  "license_location_status": "Met",
+  "license_location_justification": "https://github.com/OpenRAE/lilrae/blob/main/LICENSE",
+  "documentation_basics_status": "Met",
+  "documentation_basics_justification": "https://openrae.github.io/lilrae/getting-started/",
+  "documentation_interface_status": "Met",
+  "documentation_interface_justification": "https://openrae.github.io/lilrae/reference/cli/",
+  "sites_https_status": "Met",
+  "sites_https_justification": "The repository, package index, and both documentation hosts use HTTPS.",
+  "discussion_status": "Met",
+  "discussion_justification": "https://github.com/OpenRAE/lilrae/issues",
+  "english_status": "Met",
+  "english_justification": "Project documentation and contribution channels use English.",
+  "maintained_status": "Met",
+  "repo_public_status": "Met",
+  "repo_public_justification": "https://github.com/OpenRAE/lilrae",
+  "repo_track_status": "Met",
+  "repo_track_justification": "The public Git repository records changes, authors, and timestamps.",
+  "repo_interim_status": "Met",
+  "repo_interim_justification": "Feature branches and pull requests expose interim changes for review.",
+  "repo_distributed_status": "Met",
+  "repo_distributed_justification": "The project uses Git.",
+  "version_unique_status": "Met",
+  "version_unique_justification": "Every release has a unique PEP 440 version and Git tag.",
+  "version_semver_status": "Met",
+  "version_semver_justification": "APTL publishes three-part semantic versions.",
+  "version_tags_status": "Met",
+  "version_tags_justification": "https://github.com/OpenRAE/lilrae/tags",
+  "release_notes_status": "Met",
+  "release_notes_justification": "https://github.com/OpenRAE/lilrae/releases",
+  "release_notes_vulns_status": "Met",
+  "release_notes_vulns_justification": "Release notes identify user-visible fixes; no public APTL vulnerability with a CVE has been fixed to date.",
+  "report_process_status": "Met",
+  "report_process_justification": "https://github.com/OpenRAE/lilrae/blob/main/SUPPORT.md",
+  "report_tracker_status": "Met",
+  "report_tracker_justification": "https://github.com/OpenRAE/lilrae/issues",
+  "report_archive_status": "Met",
+  "report_archive_justification": "https://github.com/OpenRAE/lilrae/issues?q=is%3Aissue",
+  "vulnerability_report_process_status": "Met",
+  "vulnerability_report_process_justification": "https://github.com/OpenRAE/lilrae/security/policy",
+  "vulnerability_report_private_status": "Met",
+  "vulnerability_report_private_justification": "https://github.com/OpenRAE/lilrae/security/advisories/new",
+  "test_status": "Met",
+  "test_justification": "https://github.com/OpenRAE/lilrae/blob/main/CONTRIBUTING.md#verification",
+  "test_invocation_status": "Met",
+  "test_invocation_justification": "The Python suite uses pytest and the TypeScript suites use npm test.",
+  "test_continuous_integration_status": "Met",
+  "test_continuous_integration_justification": "https://github.com/OpenRAE/lilrae/actions/workflows/checks.yml",
+  "test_policy_status": "Met",
+  "test_policy_justification": "https://github.com/OpenRAE/lilrae/blob/main/CONTRIBUTING.md#making-changes",
+  "tests_are_added_status": "Met",
+  "tests_are_added_justification": "Recent feature and fix pull requests include focused regression tests.",
+  "tests_documented_added_status": "Met",
+  "tests_documented_added_justification": "https://github.com/OpenRAE/lilrae/blob/main/CONTRIBUTING.md#making-changes",
+  "warnings_status": "Met",
+  "warnings_justification": "Pre-commit, Ruff, Vale, strict MkDocs, TypeScript checks, and SonarCloud run in CI.",
+  "warnings_fixed_status": "Met",
+  "warnings_fixed_justification": "Required checks must pass before protected-branch integration.",
+  "warnings_strict_status": "Met",
+  "warnings_strict_justification": "The project uses strict documentation builds and blocking lint, type, complexity, and new-code quality gates.",
+  "no_leaked_credentials_status": "Met",
+  "no_leaked_credentials_justification": "Secret detection runs in pre-commit and CI; committed fixture credentials are intentionally public lab data.",
+  "static_analysis_status": "Met",
+  "static_analysis_justification": "SonarCloud analyzes proposed releases and a blocking gate rejects new issues.",
+  "static_analysis_common_vulnerabilities_status": "Met",
+  "static_analysis_common_vulnerabilities_justification": "SonarCloud, Trivy, pip-audit, and OSV-Scanner examine common defect and vulnerability classes.",
+  "static_analysis_often_status": "Met",
+  "static_analysis_often_justification": "Static analysis runs in the pull-request and integration-branch checks.",
+  "dynamic_analysis_status": "Met",
+  "dynamic_analysis_justification": "Property-based fuzz tests vary parser and configuration inputs; live release qualification exercises the deployed lab.",
+  "dynamic_analysis_unsafe_status": "N/A",
+  "dynamic_analysis_unsafe_justification": "APTL production source is Python and TypeScript, not a memory-unsafe language.",
+  "dynamic_analysis_enable_assertions_status": "Met",
+  "dynamic_analysis_enable_assertions_justification": "Pytest, Hypothesis, and Vitest execute with their assertions enabled.",
+  "general_comments": "The complete passing-level assessment and evidence links are maintained at https://openrae.github.io/lilrae/security/openssf-best-practices/. Account-only attestations must be confirmed by the maintainer in the badge application."
+}

lilrae-8.0.0/.claude/hooks/protect_files.sh

@@ -0,0 +1,39 @@
+#!/bin/bash
+# Block edits to sensitive files (.env, credentials, keys)
+FILE_PATH=$(jq -r '.tool_input.file_path // empty')
+
+if [[ -z "$FILE_PATH" ]]; then
+    exit 0
+fi
+
+BASENAME=$(basename "$FILE_PATH")
+
+# Block .env files, but allow committed templates (`.env.example`,
+# `.env.*.example`) since those carry placeholders, not secrets.
+if [[ "$BASENAME" == .env* ]] && [[ "$BASENAME" != *.example ]]; then
+    echo "BLOCKED: Editing $BASENAME is not allowed. These files contain secrets." >&2
+    exit 2
+fi
+
+if [[ "$BASENAME" == "local_settings.py" ]]; then
+    echo "BLOCKED: Editing $BASENAME is not allowed. These files contain secrets." >&2
+    exit 2
+fi
+
+# The config-rendering source module src/aptl/core/credentials.py is NOT a
+# secret store — it renders credentialized service config from checked-in
+# templates (ADR-028) and holds no secrets. The credential-store glob below
+# (`credentials*`) otherwise catches it; exempt this one source path so the
+# module stays editable while every real secret file (.env*, *.key, *.pem,
+# credential data files) remains protected.
+if [[ "$FILE_PATH" == */src/aptl/core/credentials.py || "$FILE_PATH" == "src/aptl/core/credentials.py" ]]; then
+    exit 0
+fi
+
+# Block key/credential files
+if [[ "$BASENAME" == *.key ]] || [[ "$BASENAME" == *.pem ]] || [[ "$BASENAME" == "credentials"* ]]; then
+    echo "BLOCKED: Editing $BASENAME is not allowed. These files contain secrets." >&2
+    exit 2
+fi
+
+exit 0

lilrae-8.0.0/.claude/settings.json

@@ -0,0 +1,25 @@
+{
+  "permissions": {
+    "allow": [
+      "mcp__aptl-reverse__reverse_info",
+      "mcp__aptl-soar__soar_get_execution",
+      "mcp__aptl-case-mgmt__cases_update_case",
+      "mcp__aptl-reverse__reverse_run_command",
+      "WebFetch(domain:raw.githubusercontent.com)",
+      "Bash(git clone:*)"
+    ]
+  },
+  "hooks": {
+    "PreToolUse": [
+      {
+        "matcher": "Edit|Write",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "$CLAUDE_PROJECT_DIR/.claude/hooks/protect_files.sh"
+          }
+        ]
+      }
+    ]
+  }
+}

lilrae-8.0.0/.claude/skills/gh-workflow-monitor/SKILL.md

@@ -0,0 +1,19 @@
+---
+name: gh-workflow-monitor
+description: Monitor GitHub workflows, propose fixes for failures, and report status
+disable-model-invocation: true
+---
+
+# GitHub Workflow Monitor
+
+Use the `gh` for GitHub operations.
+
+## Step 1: Check current branch.
+
+## Step 2: If the branch is not green, find the GitHub Actions workflow run associated with the current branch. Use the gh cli.
+
+## Step 3: Monitor the workflow run for failures.
+
+## Step 4: If the workflow run fails, propose a fix.
+
+## Step 5: If the workflow run succeeds, exit plan mode and report the status.

lilrae-8.0.0/.claude/skills/ship/SKILL.md

@@ -0,0 +1,87 @@
+---
+name: ship
+description: Ship current branch — CI, SonarCloud, code review, security review, fix all issues, merge. Assumes code is already committed and pushed.
+disable-model-invocation: true
+---
+
+# Ship Current Branch
+
+Assumes code is already committed and pushed. Handles: PR creation, CI monitoring, SonarCloud, code review, security review, fixing all issues, and merging.
+
+**IMPORTANT:** NEVER include Co-Authored-By, "Generated with Claude Code", or any Claude/AI attribution in commit messages, PR descriptions, or any other artifacts.
+
+## Phase 1: Create PR
+
+1. Determine the current branch: `git branch --show-current`
+2. Check if a PR already exists: `gh pr list --head <branch> --json number,url`
+3. If no PR exists, create one:
+   ```
+   gh pr create --base dev --title "<concise title>" --body "<description>"
+   ```
+4. Note the PR number.
+
+## Phase 2: CI Monitor
+
+1. Find the latest workflow run: `gh run list --branch <branch> --limit 1 --json status,conclusion,databaseId`
+2. If the run is in progress, watch it: `gh run watch <id>`
+3. If it failed:
+   - Get failed logs: `gh run view <id> --log-failed`
+   - Diagnose and fix the issue.
+   - `git add`, `git commit`, `git push`.
+   - Go back to step 1.
+4. If it succeeded, proceed.
+
+## Phase 3: SonarCloud Check
+
+1. Wait 60 seconds for SonarCloud analysis to propagate.
+2. Use `get_project_quality_gate_status` with project key `Brad-Edwards_aptl` to check the quality gate.
+3. Use `search_sonar_issues_in_projects` to find new issues on the current branch.
+4. If issues found:
+   - Fix them.
+   - `git add`, `git commit`, `git push`.
+   - Re-run Phase 2.
+5. If clean, proceed.
+
+## Phase 4: Code Review
+
+**CRITICAL: You MUST use the Skill tool to invoke the built-in review skill.**
+
+1. Merge dev into the current branch: `git fetch origin dev && git merge origin/dev`
+2. If there are merge conflicts, resolve them, commit, and push.
+3. Call the Skill tool with `skill="review"` to invoke the real built-in code review.
+4. After the review completes, fix ALL issues it identified.
+   - Do NOT defer ANY issues.
+   - Do NOT categorize issues as "low priority" to avoid work.
+   - You are an LLM. You have no time constraints. Fix everything.
+   - The ONLY reason to stop and escalate to the user is if a fix requires
+     a significant architectural change touching 5+ files outside the
+     current feature scope.
+5. After fixing, re-read all findings and confirm each one was addressed.
+
+## Phase 5: Security Review
+
+**CRITICAL: You MUST use the Skill tool to invoke the built-in security-review skill.**
+
+1. Call the Skill tool with `skill="security-review"` to invoke the real built-in security review.
+2. After the review completes, fix ALL issues it identified.
+   - Same rules as Phase 4: fix everything, defer nothing.
+3. After fixing, confirm all findings were addressed.
+
+## Phase 6: Final Commit & CI
+
+If ANY fixes were made in Phases 4-5:
+1. `git add` all changed files.
+2. `git commit -m "Fix code review and security review findings"`
+3. `git push`
+4. Re-run Phase 2 (CI Monitor).
+5. Re-run Phase 3 (SonarCloud).
+
+## Phase 7: Report (DO NOT MERGE)
+
+**You MUST NOT merge the PR. You MUST NOT run `gh pr merge`. The user reviews and merges.**
+
+- Summary of all changes made during the ship process
+- Review findings and what was fixed
+- Security review findings and what was fixed
+- Confirmation: CI green, SonarCloud passed, PR ready for user review
+- PR URL

lilrae-8.0.0/.claude/skills/stage/SKILL.md

@@ -0,0 +1,36 @@
+---
+name: stage
+description: Stage files, run pre-commit, fix failures, loop until clean
+disable-model-invocation: true
+---
+
+# Stage Changes
+
+## Step 1: Identify Changed Files
+
+1. Run `git status` to see all changed and untracked files.
+2. Exclude from staging: .env files, credentials, secrets, large binaries.
+
+## Step 2: Stage Files
+
+1. `git add` all relevant changed files.
+
+## Step 3: Pre-commit Loop
+
+Run up to 5 iterations:
+
+1. Run `pre-commit run` against the staged files. Never use `--all-files`
+   locally; CI/CD owns whole-tree checks.
+2. If it passes, proceed to Step 4.
+3. If it fails:
+   - Read the failure output.
+   - Fix the issues.
+   - Re-stage any modified files with `git add`.
+   - Go back to step 1.
+4. If still failing after 5 attempts, report the failure details to the user and stop.
+
+## Step 4: Report
+
+- List what is staged: `git diff --cached --name-only`
+- Confirm pre-commit passes.
+- "All files staged and pre-commit clean. Ready for commit."

lilrae-8.0.0/.claude/skills/wave-issue-coverage/SKILL.md

@@ -0,0 +1,119 @@
+---
+name: wave-issue-coverage
+description: For each DRAFT requirement in a given Ground Control wave (or all waves), ensure a GitHub issue covers it and is bidirectionally linked. Use when the user asks to "cover wave N requirements with issues", "back-fill issues for draft requirements", or similar. Requires the Ground Control MCP and `gh` CLI.
+---
+
+# Wave Issue Coverage
+
+Back-fill GitHub issue coverage for DRAFT Ground Control requirements in a given wave.
+
+## Inputs
+
+- **wave**: integer wave number (e.g. `1`, `2`, `3`) OR the literal string `all`
+  - `all` → process every wave that has DRAFT requirements, smallest wave first
+
+## Preconditions
+
+1. Read `.ground-control.yaml` at the repo root via `gc_get_repo_ground_control_context` to obtain:
+   - `project` — Ground Control project identifier
+   - `github_repo` — `owner/repo` for `gh` calls
+   These values are passed to every MCP and `gh` call in this workflow. Do not hard-code them.
+2. The GC MCP server (`mcp__ground-control__*`) must be available.
+3. `gh auth status` must be authenticated with write access to `github_repo`.
+
+## Workflow
+
+### 1. Resolve the requirement list
+
+Call `gc_list_requirements` with `project=<project>`, `status=DRAFT`, `size=200`, and:
+- `wave=<N>` if a single wave was given, OR
+- no `wave` filter if `all` was given (then group results by wave and process oldest wave first).
+
+Capture the full list of `(uid, id, title, requirement_type, priority, wave)` tuples. This is the work list.
+
+### 2. Choose progress tracker
+
+Pick based on the size of the work list:
+
+| Count | Tracker |
+|---|---|
+| ≤ 25 | `TaskCreate` — one task per requirement, processed in order |
+| > 25 | A temp file at `/tmp/wave-issue-coverage-<wave>-<timestamp>.md` with a checkbox per requirement; update inline as each completes |
+
+For the temp-file path, use a single in-progress `TaskCreate` task ("Process wave N coverage — see temp file") so the user still sees forward motion in their TaskList.
+
+### 3. Process sequentially — DO NOT parallelize
+
+For each requirement, in order:
+
+1. **Check existing GC traceability**
+   `gc_get_traceability` with the requirement UUID. Note any existing `GITHUB_ISSUE` artifact links.
+
+2. **Search GitHub for the UID**
+   `gh issue list --repo <github_repo> --state all --search "<UID> in:title,body" --json number,title,state`
+
+3. **Search GitHub for topic overlap (only if no UID match)**
+   Run a small number of focused keyword searches drawn from the requirement title/statement. The goal is to catch issues that pre-date the UID convention or were filed under a different name. Pick the strongest 1–3 keywords; do not flood with searches.
+
+4. **Decide coverage**
+   - **Issue found that fully or substantially covers the requirement** → link it and update its body (step 5).
+   - **Issue found that partially covers** → link it (step 5) AND create a new issue for the remaining scope (step 6).
+   - **No relevant issue** → create a new issue (step 6).
+
+5. **Link existing issue + update body**
+   - If GC has no link to the issue yet, call `gc_create_traceability_link` with `link_type=DOCUMENTS` (DRAFT requirements reject `IMPLEMENTS` — see Notes).
+   - Read the current issue body; if it does not already have a `## Requirements` section, prepend one:
+     ```markdown
+     ## Requirements
+
+     - <UID> — <Requirement Title>
+     ```
+     If it has one but the UID is missing, add the bullet to the existing list. Save via `gh issue edit <n> --body-file <tempfile>`.
+   - Apply labels (step 7).
+
+6. **Create new issue**
+   - Call `gc_create_github_issue` with `uid=<UID>`, `project=<project>`, `repo=<github_repo>`, `extra_body="## Requirements\n\n- <UID> — <Title>"`, and `labels=[...]` (step 7 list).
+   - The MCP tool will return a warning that the auto-link failed because the requirement is DRAFT (it tries `IMPLEMENTS`). Manually create the link with `gc_create_traceability_link` using `link_type=DOCUMENTS`.
+
+7. **Tag the issue**
+   Every issue touched or created in this workflow must carry, at minimum:
+   - `requirement`
+   - `wave-<N>` (the requirement's wave; create the label if it does not exist via `gh label create wave-<N> --description "Wave <N> requirement" --color B60205`)
+
+   Plus 1–3 topic-specific labels chosen from the repo's existing label set. Pick conservatively; do not invent new topic labels. Common picks:
+   - GC-D* (GitHub integration) → `integrations`, `backend`
+   - GC-E* (traceability semantics) → `domain`, `backend`
+   - GC-L* (MCP tools) → `mcp-grc`, `api`
+   - GC-C* (analysis / quality gates) → `quality`, `ci-cd`
+   - GC-Q* (web UI) → `frontend`, `ui`
+   - GC-O* (workflow / agents) → `agents`, `workflow`, `documentation`
+   - GC-P* (platform / security) → `security` or `auth`
+   - TC-* (test management) → `testing`, plus `data-model` / `domain` / `frontend` as fits
+
+   Apply with `gh issue edit <n> --add-label "a,b,c"`. If a pre-existing issue already has labels, add to them; do not strip.
+
+8. **Mark the task / temp-file row complete** and move to the next requirement. Never advance two requirements in parallel.
+
+### 4. Report back
+
+Single short summary: how many requirements processed, how many already had coverage, how many issues created. Do NOT enumerate everything done — the user will read the TaskList or temp file if they want detail.
+
+## Notes
+
+- **DRAFT requirements + IMPLEMENTS link**: `gc_create_traceability_link` with `link_type=IMPLEMENTS` rejects DRAFT requirements with `422`. Always use `DOCUMENTS` for issue → DRAFT links. This matches what `gc_create_github_issue` is *trying* to do but the auto-link inside that tool currently uses `IMPLEMENTS` and silently warns; do the link yourself.
+- **Issue body `## Requirements` section**: per `docs/DEVELOPMENT_WORKFLOW.md`, the `/implement` skill parses this section. Format must be a markdown H2 named exactly `## Requirements` followed by a bulleted list, each bullet starting with the UID. This is what makes the issue routable through `/implement` later.
+- **Sequential, not parallel**: the tooling will let you fan out, but the user has explicitly asked for serial processing every time. Honor it.
+- **Don't invent labels**: if a topic label doesn't exist in `gh label list`, skip it rather than creating it. The only label this skill creates is `wave-<N>` when missing.
+- **Idempotency**: re-running this skill on the same wave should be a no-op for already-covered requirements. The presence of a `GITHUB_ISSUE` traceability link AND a `## Requirements` section listing the UID AND `requirement` + `wave-<N>` labels means there is nothing to do; move on.
+
+## Quick reference — MCP calls
+
+```text
+gc_get_repo_ground_control_context(repo_path=<absolute repo path>)
+gc_list_requirements(project, status="DRAFT", wave=<N>, size=200)
+gc_get_traceability(id=<requirement UUID>)
+gc_create_github_issue(uid, project, repo, extra_body, labels)
+gc_create_traceability_link(requirement_id, artifact_type="GITHUB_ISSUE",
+                            artifact_identifier="#<n>", artifact_title,
+                            artifact_url, link_type="DOCUMENTS")
+```

lilrae-8.0.0/.cursor/environment.json

@@ -0,0 +1,4 @@
+{
+    "agentCanUpdateSnapshot": true,
+    "install": "apt-get update && apt-get install -y nodejs npm jq && cd red_team/kali_mcp && npm install && npm run build"
+}

lilrae-8.0.0/.cursor/rules/no-jumping-ahead.mdc

@@ -0,0 +1,50 @@
+---
+description:
+globs:
+alwaysApply: true
+---
+# DO NOT JUMP AHEAD
+
+ALWAYS follow these rules when working on this codebase:
+
+1. **ONLY do what is explicitly requested** - Do not add extra features, scripts, or files that weren't asked for
+2. **DO NOT assume what the user wants** - If unclear, ask for clarification rather than making assumptions
+3. **CHECK before going beyond the request** - If you think something additional might be helpful, ask first
+4. **STOP when the task is complete** - Don't continue adding "helpful" extras
+5. **RESPECT the user's workflow** - They know their codebase and requirements better than you do
+
+## What NOT to do:
+- Create helper scripts without being asked
+- Add complex setup procedures when simple ones exist
+- Generate documentation for features that don't exist yet
+- Modify files beyond what was specifically requested
+- Add "best practices" that weren't requested
+
+## What TO do:
+- Answer the specific question asked
+- Make only the changes explicitly requested
+- Ask for clarification when requirements are unclear
+- Keep responses focused and concise
+- Respect existing code patterns and structure
+
+**Remember: Being helpful means doing exactly what was asked, not what you think might be helpful.**
+
+# WRITING STYLE GUIDELINES
+
+ALWAYS follow these writing rules for this technical/cyber audience:
+
+## DO NOT:
+- Use marketing language, boosterism, or sales-y content
+- Write verbose explanations or "value propositions"
+- Use excessive emojis or excitement
+- Create bulleted lists with bold formatting everywhere
+- Write like you're selling something
+
+## DO:
+- Use plain, simple, direct language
+- Write for busy technical professionals
+- Be concise and to the point
+- Focus on facts and functionality
+- Remember: technical people get turned off by marketing speak
+
+**Remember: This audience wants information, not persuasion. Write documentation like you're talking to a colleague, not a prospect.**

lilrae-8.0.0/.dockerignore

@@ -0,0 +1,26 @@
+.git
+.github
+.venv
+.pytest_cache
+.mypy_cache
+__pycache__
+*.pyc
+node_modules
+**/node_modules
+# `containers/` is intentionally NOT excluded: the in-process target
+# images (ad / dns / fileshare / webapp; issue #248) and the remaining
+# `wazuh-sidecar` image build from the repo root and need access to the
+# shared `containers/_wazuh-agent/` files plus their own per-container
+# subdirectory. Per-container build contexts (victim, workstation, kali,
+# etc.) read their own `.dockerignore` so they're unaffected.
+docs/
+notes/
+coverage.xml
+.coverage
+*.egg-info
+dist/
+build/
+.svelte-kit
+web/node_modules
+web/.svelte-kit
+web/tests

lilrae-8.0.0/.env.example

@@ -0,0 +1,84 @@
+# APTL Lab Credentials
+# Copy this file to .env; `aptl lab start` hydrates it, filling every
+# CHANGE_ME placeholder with a runnable value (randomizing real secrets). You
+# only need to supply values you specifically want to pin.
+# The .env file is gitignored and will not be committed.
+#
+# NOTE: INDEXER_* and DASHBOARD_* below are NOT user-selectable. They must match
+# the OpenSearch demo-user hashes baked into the checked-in
+# config/wazuh_indexer/internal_users.yml (admin=SecretPassword,
+# kibanaserver=kibanaserver); the indexer never recomputes those hashes from
+# .env. Leave the placeholders (hydration fills the correct fixtures) or set the
+# exact fixture values. Any other value is reconciled back at start with a
+# warning, because the indexer would otherwise reject it.
+
+# Wazuh Indexer / OpenSearch admin credentials (auto-managed fixture)
+INDEXER_USERNAME=admin
+INDEXER_PASSWORD=CHANGE_ME_indexer_password
+
+# Wazuh Dashboard internal user (auto-managed fixture)
+DASHBOARD_USERNAME=kibanaserver
+DASHBOARD_PASSWORD=CHANGE_ME_dashboard_password
+
+# Wazuh API credentials
+API_USERNAME=wazuh-wui
+API_PASSWORD=CHANGE_ME_api_password
+
+# Wazuh cluster key
+WAZUH_CLUSTER_KEY=CHANGE_ME_cluster_key
+
+# Web control-plane API token (ADR-039). Required when running the optional
+# aptl-web-api and aptl-web-ui services. The API rejects missing, empty, or
+# placeholder values at runtime. Generate a real token with:
+#   python3 -c 'import secrets; print(secrets.token_hex(32))'
+APTL_API_TOKEN=CHANGE_ME_api_token
+
+# Identity of the aptl-web-api container (issue #1193). It never runs as root:
+# it runs as the user that owns this project (the one who runs `aptl lab
+# start`), so it can read the owner-only lab state under .aptl/, and joins only
+# the Docker socket's group. Set both from the project owner's shell:
+#   echo "APTL_WEB_API_USER=$(id -u):$(id -g)"
+#   echo "APTL_DOCKER_SOCKET_GID=$(stat -c %g /var/run/docker.sock)"
+# Left unset, the web API container refuses to start.
+APTL_WEB_API_USER=CHANGE_ME_uid:gid
+APTL_DOCKER_SOCKET_GID=CHANGE_ME_docker_socket_gid
+
+# Enterprise services
+DB_PASSWORD=techvault_db_pass
+AD_ADMIN_PASSWORD=Admin123!
+
+# SOC tools
+MISP_ADMIN_PASSWORD=MispAdmin2024!
+# MISP REST API auth key. Used by both the MISP server (as ADMIN_KEY) and
+# every downstream consumer (aptl-misp-suricata-sync, mcp-threatintel, etc.).
+# Generate a fresh 40-character alphanumeric value with:
+#   tr -dc A-Za-z0-9 </dev/urandom | head -c 40 ; echo
+# The placeholder below is rejected by aptl-misp-suricata-sync at startup
+# so the lab fails loudly if you forget to replace it.
+MISP_API_KEY=PLEASEREPLACEMEPLEASEREPLACEMEPLEASEREPLACE
+# TLS verification for SOC stack consumers connecting to MISP.
+# SEC-006 / ADR-034 (issue #258) made the lab-managed CA the default
+# trust anchor: ServiceConfig defaults MISP_VERIFY_SSL to true, and the
+# misp-suricata-sync container mounts the CA bundle at
+# /etc/lab-ca/lab-ca.pem. Leaving these lines commented out (or unset)
+# lets the in-code defaults win. Override only for local debugging, e.g.
+# while iterating on a self-signed MISP fork:
+#   MISP_VERIFY_SSL=false
+#   MISP_CA_CERT_PATH=
+# MISP_VERIFY_SSL=true
+# MISP_CA_CERT_PATH=/etc/lab-ca/lab-ca.pem
+THEHIVE_SECRET=aptl-thehive-lab-secret-key-2024-purple
+SHUFFLE_ADMIN_PASSWORD=ShuffleAdmin2024!
+SHUFFLE_API_KEY=31a211c4-ea5c-4a49-b022-5e2434e758a7
+
+# Grafana (OTel observability stack)
+GRAFANA_ADMIN_USER=admin
+GRAFANA_ADMIN_PASSWORD=CHANGE_ME_grafana_password
+
+# Host-port publishing. Every service's published host port has a
+# `${APTL_HP_<SERVICE>_<PORT>:-default}` override. `aptl lab start` probes
+# each default and, if it is already in use on this host (e.g. an editor's
+# port-forwarding, another app), automatically publishes that service on a
+# free port instead and reports the real port in the start summary. Set any of
+# these to pin a specific port; a value you set here is always honored as-is.
+# APTL_HP_WAZUH_DASHBOARD_5601=443

lilrae-8.0.0/.gc/plan-rules.md

@@ -0,0 +1,44 @@
+# LilRAE plan rules
+
+Mandatory constraints the `/implement` skill applies during plan phase.
+
+- One issue = one PR. A delivery PR MUST address every acceptance criterion
+  of its issue, including code, documentation, and tests. Extend the existing
+  PR; do not distribute one issue across multiple PRs. If an issue is too large,
+  create smaller linked issues with explicit acceptance criteria and one
+  complete PR per smaller issue. The parent tracks their delivery.
+- Plans that add or change Python code MUST include corresponding pytest
+  tests in `tests/`. Use `pytest -m fuzz` for property-based tests
+  (the default test run skips them per `pyproject.toml`).
+- Plans that add or change MCP TypeScript servers (anything under `mcp/`)
+  MUST include corresponding vitest tests in that server's `tests/`
+  directory.
+- Plans that add or change web frontend code MUST include corresponding
+  vitest tests in `web/tests/`.
+- Plans that touch `mcp/aptl-mcp-common` MUST account for the fact that
+  every MCP server consumes it. Run only targeted common and consumer tests
+  locally; CI/CD rebuilds and tests every dependent MCP before the change is
+  considered complete.
+- Plans that change any Compose asset (`docker-compose*.yml`), container
+  Dockerfiles, or `config/` files MUST include focused local contract tests.
+  CI/CD owns the clean `aptl lab stop -v && aptl lab start` validation on a
+  fresh machine — the lab is the primary product, not the codebase.
+- Local verification MUST remain change-scoped: targeted pytest or Vitest
+  paths plus `pre-commit run` on staged files. Bare/full suites,
+  `pre-commit run --all-files`, whole-tree prose checks, dependency checks, and
+  coverage runs are CI/CD-only.
+- Plans MUST NOT edit `CHANGELOG.md` or the version. Releases are automated by
+  release-please from Conventional Commit PR titles: `feat:` (minor),
+  `fix:`/`perf:` (patch), `feat!:` or a `BREAKING CHANGE:` footer (major);
+  `docs`/`chore`/`refactor`/`test`/`ci`/`build` do not release. The PR title is
+  the changelog entry, so make it a clear Conventional Commit. See
+  `docs/releasing.md`.
+- New code MUST use `lilrae` naming: a new module, package, service,
+  environment variable (`LILRAE_`), resource name, or configuration file is
+  named for LilRAE, not APTL. Code that extends an existing interface MUST keep
+  that interface's current identifiers (for example the `aptl` import root,
+  `aptl` CLI, `aptl.*` entry-point groups, existing config fields, `APTL_*`
+  variables, and runtime resource names); add no alias, shim, or parallel
+  `lilrae` spelling. Renaming an existing identifier needs its own
+  compatibility decision. See
+  [ADR-062](../docs/adrs/adr-062-lilrae-name-and-naming-convention.md).