Compare commits

...

58 Commits

Author SHA1 Message Date
Daniel Bedeleanu
00ee4cf9c5 Build [v1.9.19] 2026-04-14 20:44:01 +03:00
Daniel Bedeleanu
fcb187974e Build [v1.9.18] 2026-04-13 23:43:52 +03:00
Daniel Bedeleanu
1fff658d3c Build [v1.9.16] (Open Gateway: Verified SSL Permission check) 2026-04-13 22:48:26 +03:00
Daniel Bedeleanu
826b264a70 Build [v1.9.15] (The Dynamic Shield: On-Demand TLS Catch-all) 2026-04-13 22:43:40 +03:00
Daniel Bedeleanu
94f1a515b7 Build [v1.9.14] (Protocol Lock: Explicit HTTPS & Handshake Debug) 2026-04-13 22:37:50 +03:00
Daniel Bedeleanu
4dc0ce50e7 Build [v1.9.13] (Bare Metal: Fixed Caddy Syntax & Universal Binding) 2026-04-13 22:31:04 +03:00
Daniel Bedeleanu
ee7e7b7bd7 Build [v1.9.12] (Secure Seal & LDAP Sync: Custom Caddy & Config Volume) 2026-04-13 22:25:19 +03:00
Daniel Bedeleanu
9d7e4f0ca3 Build [v1.9.11] (The Convergence: Manual Login & Runtime Discovery) 2026-04-13 22:15:57 +03:00
Daniel Bedeleanu
bdf6d605cd Build [v1.9.10] (Access & SSL Recovery: Fixed Admin info and Explicit IP Proxy) 2026-04-13 22:07:15 +03:00
Daniel Bedeleanu
a2f6cab492 Build [v1.9.9] (Emergency: Direct HTTP Fallback & Diagnostic Logs) 2026-04-13 21:57:51 +03:00
Daniel Bedeleanu
476fda7203 Build [v1.9.8] (Final Stability: Static Internal Port Mapping) 2026-04-13 21:48:40 +03:00
Daniel Bedeleanu
9348336709 Build [v1.9.7] (Fix ERR_SSL_PROTOCOL_ERROR: Explicit HTTPS in Caddyfile) 2026-04-13 21:42:58 +03:00
Daniel Bedeleanu
e5194a1dbb Build [v1.9.6] (Fix: Include deploy.sh in production bundle) 2026-04-13 21:36:23 +03:00
Daniel Bedeleanu
7c3d0e102f Build [v1.9.5] (Bulletproof Deployment with visible inventory.env and deploy.sh) 2026-04-13 21:32:49 +03:00
Daniel Bedeleanu
a0eaddf994 Build [v1.9.4] (Single Source of Truth: Consolidated Configuration) 2026-04-13 21:15:19 +03:00
Daniel Bedeleanu
30be967887 Build [v1.9.3] (Fix Host-Side Port Interpolation with Root .env) 2026-04-13 21:12:55 +03:00
Daniel Bedeleanu
2b8d0b3f43 Build [v1.9.2] (Fix Environment Variable Overriding in Docker Compose) 2026-04-13 20:58:10 +03:00
Daniel Bedeleanu
07b15c8e01 Build [v1.9.1] (CORS Dynamic IP Resolution Fix) 2026-04-13 20:52:29 +03:00
Daniel Bedeleanu
65cc0c7b6d Official Release [v1.9.0] (Stability Milestone • Automatic Git Commit ID) 2026-04-13 20:41:10 +03:00
Daniel Bedeleanu
f137ded5aa Build [v1.8.9] (Runtime Permission Healing for Docker Volumes) 2026-04-13 20:32:40 +03:00
Daniel Bedeleanu
946f1787c7 Build [v1.8.8] (Complete Frontend Build Cleaned & Verified) 2026-04-13 20:24:21 +03:00
Daniel Bedeleanu
09be0b401d Build [v1.8.7] (Fix strict Type error in logs page) 2026-04-13 20:07:55 +03:00
Daniel Bedeleanu
3069a921e7 Build [v1.8.6] (TypeScript unknown catch type fix) 2026-04-13 19:56:27 +03:00
Daniel Bedeleanu
55e3cf5042 Build [v1.8.5] (Self-contained Frontend Build) 2026-04-13 19:50:28 +03:00
Daniel Bedeleanu
c874d27d64 Build [v1.8.4] (Satisfy frontend relative VERSION.json path) 2026-04-13 19:44:52 +03:00
Daniel Bedeleanu
939ad8648d Build [v1.8.3] (Explicit directory creation in bundle) 2026-04-13 19:39:33 +03:00
Daniel Bedeleanu
6f6caf3c5a Build [v1.8.2] (Fix missing scripts in bundle) 2026-04-13 19:38:11 +03:00
Daniel Bedeleanu
5e648002f0 Build [v1.8.1] (Fix Docker Context) 2026-04-13 19:36:06 +03:00
Daniel Bedeleanu
81b775c9ae Build [v1.8.0] 2026-04-13 19:23:48 +03:00
Daniel Bedeleanu
994920bda2 Build [v1.7.0] - GitGuard - Infrastructure Hardening 2026-04-12 22:45:27 +03:00
Daniel Bedeleanu
0a6368b9f6 modificari de documentatii dupa o implementare noua 2026-04-12 21:43:08 +03:00
Daniel Bedeleanu
26e8f034a2 Update save_version.py: Added automatic master branch synchronization 2026-04-12 21:32:55 +03:00
Daniel Bedeleanu
2e5c666cc8 Build [v1.5.0] - Box Management & Label Printing 2026-04-12 21:30:50 +03:00
Daniel Bedeleanu
e383b97d44 docs: finalized v1.4.1 session logs and architecture security section 2026-04-12 10:49:48 +03:00
Daniel Bedeleanu
50ae3671c9 Build [v1.4.1] - Security hardening, PWA and UI refinements 2026-04-12 10:45:57 +03:00
Daniel Bedeleanu
f3d861b1a2 Build [v1.4.0] - Audit Dashboard & LDAP Restoration 2026-04-12 09:39:17 +03:00
Daniel Bedeleanu
5cceba21f4 Fix version naming format: v.X.Y.Z → vX.Y.Z 2026-04-12 07:32:16 +03:00
Daniel Bedeleanu
161a182281 Build [v.1.3.9] 2026-04-12 07:29:58 +03:00
Daniel Bedeleanu
38e9428109 chore: update VERSION.json commit hash to 0869ab8c 2026-04-11 19:48:02 +03:00
Daniel Bedeleanu
0869ab8cdd chore: purge .npx_cache/ and scratch/npm_cache/ from git index [v1.3.8]
These directories were already tracked before being added to .gitignore.
Removed 3350 cached files from git index via 'git rm --cached -r'.
Files remain on disk but are no longer tracked by git.
2026-04-11 19:47:20 +03:00
Daniel Bedeleanu
106f46e9f8 chore: update VERSION.json commit hash to 955b1e86 2026-04-11 19:37:38 +03:00
Daniel Bedeleanu
955b1e86e5 security: harden gitignore and add config example files [v1.3.7]
- Expanded .gitignore: root venv, npx_cache, AI metadata (.remember, .claude),
  data/ (SQLite DB), frontend/config/, frontend/public/icons/, certificates,
  docker-compose.override.yml
- Removed backend/config/ldap_config.json from git tracking (contains real IPs/credentials)
- Added backend/config/ldap_config.json.example with placeholder template
- Updated backend/.env.example: added JWT_SECRET_KEY, ALLOWED_ORIGINS, DATA_DIR, LOGS_DIR
2026-04-11 19:37:16 +03:00
Daniel Bedeleanu
6981cadb57 changed_version_naming 2026-04-11 18:44:24 +03:00
Daniel Bedeleanu
704934165f Build [v.1.3.6] 2026-04-11 17:14:22 +03:00
Daniel Bedeleanu
775808506f fix: convert user_id to string for JWT sub claim (JWT spec requirement) 2026-04-11 15:30:31 +03:00
Daniel Bedeleanu
cee93fe53c debug: log DATA_DIR and database path at startup 2026-04-11 15:28:53 +03:00
Daniel Bedeleanu
c95d095f9f debug: add JWT validation logging to diagnose 401 errors 2026-04-11 15:25:51 +03:00
Daniel Bedeleanu
a8d74f3ae8 debug: add detailed logging to login response handling 2026-04-11 15:14:54 +03:00
Daniel Bedeleanu
d6e7a8d2a4 debug: add console logging to token save and request interceptor
- Log when saveToken is called with token details
- Log when request interceptor checks for token
- Log when Authorization header is set or token is missing
- Helps diagnose 401 Unauthorized issues after login
2026-04-11 15:11:25 +03:00
Daniel Bedeleanu
c1b8d2d8b9 fix: use absolute paths for DATA_DIR and LOGS_DIR in start_server.sh
- Resolves sqlite3.OperationalError when database path is relative
- Uses script directory as base for all relative paths
- Ensures consistent behavior regardless of working directory
2026-04-11 15:07:51 +03:00
Daniel Bedeleanu
02a4951901 refactor: centralize configuration in backend/config/ and frontend/config/
- Move ldap_config.json from ./data/ to backend/config/
- Update users.py to read LDAP config from backend/config/ldap_config.json
- Create frontend/config/ directory for future frontend configs
- DATA_DIR still used for database and runtime files in ./data/
- Update .gitignore to track backend/config/ but ignore runtime data dirs
2026-04-11 15:06:56 +03:00
Daniel Bedeleanu
ac1703e6c2 fix: set DATA_DIR and LOGS_DIR environment variables in start_server.sh
- DATA_DIR=./data points backend to correct config location
- Ensures ldap_config.json and database are found consistently
- Matches docker-compose setup
2026-04-11 15:04:05 +03:00
Daniel Bedeleanu
a6d2d176ba debug: add detailed LDAP authentication logging with error traceback 2026-04-11 15:02:57 +03:00
Daniel Bedeleanu
6e58cce73a fix: restore original LDAP configuration with correct group mappings
- Use proper group names: inventory_admins (admin), inventory_users (user)
- Use relative groups_dn: 'ou=groups' (not absolute path)
- Matches original user's GUI-configured settings
2026-04-11 15:01:12 +03:00
Daniel Bedeleanu
7d821d1f7b config: add LDAP configuration for LLDAP server at 192.168.84.107:3890 2026-04-11 14:59:16 +03:00
Daniel Bedeleanu
c816cb4630 fix: enable DEBUG logging for development (configurable via LOG_LEVEL env var) 2026-04-11 14:56:13 +03:00
Daniel Bedeleanu
3c8d50162b debug: add detailed logging to login authentication flow
- Log when local auth succeeds/fails
- Log when password mismatch occurs
- Log LDAP auth attempts and failures
- Helps diagnose why login is returning 401
2026-04-11 14:55:31 +03:00
Daniel Bedeleanu
483a747600 fix: CORS configuration for both docker-compose and start_server.sh deployments
- Update start_server.sh to auto-detect local IP and export ALLOWED_ORIGINS
- Includes both localhost and detected IP on HTTP/HTTPS proxy ports
- Export JWT_SECRET_KEY with ephemeral key if not set
- Fix Romanian comments in docker-compose.yml to English
- Document two deployment methods in SESSION_STATE.md
2026-04-11 14:44:00 +03:00
3451 changed files with 6119 additions and 55804 deletions

View File

@@ -0,0 +1,55 @@
# Superpowers Rules (Always-On)
These rules apply to ALL work unless the user explicitly opts out.
## 1) Plan gate for non-trivial work
If the task is anything beyond a tiny change, do NOT edit code immediately.
You MUST:
1) Brainstorm briefly (goal, constraints, risks, acceptance criteria)
2) Write a step-by-step plan with verification steps
3) Ask the user to approve the plan
Only after approval may you implement.
### Execute-plan gate (Superpowers parity)
After the user approves a plan, do NOT begin implementation automatically.
You MUST pause and instruct the user to run: `/superpowers-execute-plan`
Only begin implementation after `/superpowers-execute-plan` is invoked,
unless the user explicitly says to proceed without it.
### What counts as "tiny"?
- single-file change
- obvious edit
- low risk
Even then: do a mini-plan (35 steps) and include verification.
## 2) Verification is mandatory
After implementation, you MUST provide:
- exact commands to verify (tests/lint/run)
- and results if you were able to run them
## 3) Prefer TDD / regression tests
- If fixing a bug: add a regression test if practical
- If adding behavior: add/adjust tests when practical
If tests arent feasible, provide a concrete alternative verification path.
## 4) Review pass required
Before final response, do a review pass and list issues by severity:
- Blocker / Major / Minor / Nit
## 5) Safety
- Never log secrets
- Add timeouts, retries, and idempotency for API automations
- Fail safe (no silent data loss)
## Artifact persistence (mandatory)
Any brainstorm, plan, review, or finish output must be written to disk under:
`artifacts/superpowers/`
Do not leave these as IDE-only documents.
After writing, confirm the file exists.
## Persistence enforcement
When a workflow requires saving an artifact to `artifacts/superpowers/`, you MUST ensure the file exists on disk.
Preferred method: use `python .agent/skills/superpowers-workflow/scripts/write_artifact.py --path <...>`.
If you cannot execute commands, instruct the user to save the output manually.

View File

@@ -0,0 +1,37 @@
---
name: superpowers-brainstorm
description: Produces a structured brainstorm: goals, constraints, risks, options, recommendation, and acceptance criteria. Use before non-trivial implementation or design changes.
---
# Brainstorm Skill
## When to use this skill
- before implementing non-trivial features
- before refactors with unclear scope
- before debugging complex issues
- before designing an automation workflow
## Brainstorm template (use this exact structure)
### Goal
- (12 sentences)
### Constraints
- (tech stack, time, compatibility, performance, “must not change”, etc.)
### Known context
- (what exists today; relevant files/components; current behavior)
### Risks
- (security, data loss, regressions, surprising side effects)
### Options (24)
For each option include:
- Summary
- Pros / cons
- Complexity / risk
### Recommendation
- Pick one option and explain why
### Acceptance criteria
- Bullet list of verifiable outcomes

View File

@@ -0,0 +1,35 @@
---
name: superpowers-debug
description: Systematic debugging: reproduce, isolate, form hypotheses, instrument, fix, and add regression tests. Use when troubleshooting errors, failing tests, or unexpected behavior.
---
# Debug Skill
## When to use this skill
- runtime errors, flaky tests, wrong outputs
- “it used to work” regressions
- performance or timeout problems (initial triage)
## Debug workflow (do not skip steps)
1. **Reproduce**
- Capture exact error, inputs, environment, command.
2. **Minimize**
- Reduce to smallest repro (one file, one function, smallest dataset).
3. **Hypotheses (25)**
- Rank by likelihood.
4. **Instrument**
- Add temporary logging/assertions or use existing diagnostics.
5. **Fix**
- Smallest change that removes root cause.
6. **Prevent**
- Add regression test or permanent guard/validation.
7. **Verify**
- Run the failing case + relevant suites.
## Reporting format
- Symptom
- Repro steps
- Root cause
- Fix
- Regression protection
- Verification

View File

@@ -0,0 +1,32 @@
---
name: superpowers-finish
description: Finalizes work: runs verification, summarizes changes, notes follow-ups, and ensures repo hygiene. Use at the end of an implementation or debugging session.
---
# Finish Skill
## When to use this skill
- at the end of any non-trivial change set
- after a bug fix or feature is implemented
- before handing off work to a teammate/user
## Finish checklist
- Run verification commands (tests, lint, build, typecheck if relevant)
- Confirm acceptance criteria are met
- Summarize what changed (by area/file)
- Call out any risks or follow-ups
- Note how to rollback if applicable
## Output format
### Verification
- Commands run:
- Results:
### Summary of changes
- Bullet list
### Follow-ups
- Bullet list (only if needed)
### How to validate manually (if applicable)
- Steps

View File

@@ -0,0 +1,30 @@
---
name: superpowers-plan
description: Writes an implementation plan with small steps, exact files to touch, and verification commands. Use before making non-trivial changes.
---
# Planning Skill
## When to use this skill
- any multi-file change
- any change that impacts behavior, data, auth, billing, or production workflows
- any debugging that needs systematic isolation
## Planning rules
- Steps should be **small** (210 minutes each).
- Every step must include **verification**.
- Prefer **incremental deliverables** (avoid “big bang” edits).
- Identify **rollback** and **risk controls** early.
## Plan format (use this exact structure)
### Goal
### Assumptions
### Plan
1. Step name
- Files: `path/to/file.ext`, `...`
- Change: (12 bullets)
- Verify: (exact commands or checks)
2. ...
### Risks & mitigations
### Rollback plan

View File

@@ -0,0 +1,97 @@
---
name: superpowers-python-automation
description: Implements reliable automations in Python for REST APIs: httpx/requests patterns, retries, timeouts, pagination, typing, config, logging, and tests. Use when writing Python scripts/services that call external APIs.
---
# Python Automation Skill
This skill provides concrete Python patterns to implement robust REST API automations.
## When to use this skill
- Python scripts that call one or more REST APIs
- ETL jobs, sync tools, webhook handlers
- CLI tools or small services that integrate external systems
## Preferred stack (defaults)
- HTTP client: **httpx** (preferred) or requests
- Config: env vars + `.env` (optional) with pydantic-settings if appropriate
- Logging: stdlib `logging` with structured-ish fields
- Testing: pytest (+ respx for httpx mocking when useful)
If the project already uses different tools, follow project conventions.
---
## Reference architecture (small but scalable)
- `client.py`: API client wrapper (auth headers, retries, pagination helpers)
- `models.py`: typed payload models (dataclasses or pydantic)
- `sync.py`: orchestration logic (fetch -> transform -> upsert)
- `main.py`: CLI entrypoint
- `tests/`: unit tests for transform + client behavior
## HTTP rules (mandatory)
- Always set timeouts (connect + read)
- Centralize request sending in one function so retries/logging are consistent
- Never log secrets (Authorization headers, tokens)
### Retry policy guidance
Retry on:
- network errors/timeouts
- 429 (respect Retry-After when present)
- 500599
Optional: 408, and 409 only if operation is safe and semantics known
Do NOT retry on:
- most 400499 (unless explicitly safe)
### Timeouts
- Set explicit timeouts; do not rely on defaults.
- Use smaller connect timeout; moderate read timeout.
---
## Pagination patterns
Support at least one helper that can handle:
- `next` URL in response
- cursor token in response
- page/limit parameters
Add a hard stop:
- max pages OR max items OR max elapsed time
---
## Idempotency patterns (Python)
Choose and document:
- Use an `Idempotency-Key` header when supported
- Upsert using a stable `external_id`
- Persist a lightweight state store:
- simplest: SQLite file (recommended for OSS)
- alternative: JSONL log + compaction
Minimum: ensure repeated runs dont create duplicates.
---
## Observability (Python)
Minimum logs should include:
- `run_id`
- request: method, url/path, status_code, elapsed_ms, attempt
- record counts: processed/created/updated/skipped/failed
Also include a final summary log line.
---
## Verification requirements
For non-trivial work, add:
- unit tests for mapping/transform logic
- at least one test for pagination or retry behavior (mocked)
- a “dry-run” CLI flag (prints intended writes)
---
## Output format when writing code
- Provide a small directory layout
- Explain how to configure env vars
- Include exact commands to run (and test)

View File

@@ -0,0 +1,109 @@
---
name: superpowers-rest-automation
description: Builds reliable automations that integrate with REST APIs: auth, pagination, retries, rate limits, idempotency, webhooks, data mapping, and safe error handling. Use when calling external APIs, syncing systems, or building ETL-style workflows.
---
# REST Automation Skill
This skill enforces reliability and safety when building automations that call REST APIs.
## When to use this skill
Use whenever the task involves:
- calling external REST APIs (CRUD, search, sync)
- integrating 2+ systems (ETL, iPaaS-like flows)
- webhooks, polling, or scheduled jobs
- data ingestion, normalization, enrichment, deduplication
## Default design principles
- **Idempotent by design**: repeats should not create duplicates or corrupt data.
- **Observable**: logs/metrics correlate each run and each API call.
- **Fail safe**: handle partial failures; avoid silent data loss.
- **Rate-limit aware**: backoff and respect vendor limits.
- **Least privilege**: handle secrets safely, avoid overbroad scopes.
---
## Checklist (apply unless irrelevant)
### 1) Define the contract
- Inputs (format, required fields, validation)
- Outputs (where data goes, expected shape)
- Success criteria (what “done” means)
- Non-goals (what the automation will not do)
### 2) Authentication & secrets
- Identify auth type: API key, OAuth2, JWT, mTLS
- Never hardcode secrets in code or logs
- Support secret injection via env vars / secret manager
- Plan token refresh if applicable (OAuth2)
### 3) Idempotency & deduplication
Pick at least one:
- Use provider idempotency keys (if supported)
- Use stable external IDs (e.g., `external_id` field) for upserts
- Keep a local/state store mapping source IDs -> target IDs
- Use deterministic hashes for dedupe when no stable ID exists
Document the idempotency strategy explicitly.
### 4) Pagination & incremental sync
- Detect pagination style: `next` link, cursor, page+limit, offset+limit
- Ensure loops terminate safely (max pages / max time)
- Prefer incremental sync using `updated_since`/ETag/If-Modified-Since when possible
- Handle out-of-order updates and late-arriving events
### 5) Retries, backoff, and timeouts
- Set **timeouts** for connect/read
- Retry on transient errors: network failures, 429, 5xx (with limits)
- Use exponential backoff with jitter if possible
- Do **not** retry on most 4xx (except 408/409/429 depending on semantics)
- Cap retries and surface failures clearly
### 6) Rate limits & quotas
- Respect `Retry-After` and rate-limit headers
- Implement adaptive backoff on 429
- Consider batch endpoints to reduce call volume
- Avoid bursty concurrency unless explicitly safe
### 7) Data mapping & validation
- Explicit mapping layer (source -> normalized -> target)
- Validate required fields and types
- Normalize common formats (dates, enums, currency, locales)
- Handle nullability and partial payloads
- Record rejected records with reasons (dont silently drop)
### 8) Error handling strategy
Choose and document per error class:
- **Skip with log** (non-critical record)
- **Retry** (transient)
- **Quarantine** (store failing payload for later)
- **Fail the run** (systemic issue)
Ensure the workflow reports a clear summary at the end.
### 9) Observability & audit trail
Minimum:
- Run ID / correlation ID
- Per-request logs: method, path (not full secrets), status, latency, attempt count
- Counters: processed, created, updated, skipped, failed
Prefer structured logs (JSON) if possible.
### 10) Webhooks (if involved)
- Verify signature (if provided)
- Handle replay (idempotency for event IDs)
- Respond quickly; process async if needed
- Store raw event payloads (optional but recommended)
### 11) Safety controls
- Dry-run mode (no writes)
- Limit scope (max records per run)
- “Kill switch” config flag
- Backups/rollback plan for destructive operations
---
## Output requirements (when producing a solution)
Include:
- Idempotency strategy (13 bullets)
- Retry/backoff policy
- Pagination/incremental sync approach (if relevant)
- Error handling strategy + what gets logged/quarantined
- Verification plan (tests or a safe sandbox run plan)

View File

@@ -0,0 +1,33 @@
---
name: superpowers-review
description: Reviews changes for correctness, edge cases, style, security, and maintainability with severity levels (Blocker/Major/Minor/Nit). Use before finalizing changes.
---
# Review Skill
## When to use this skill
- before delivering final code changes
- after implementing a planned set of steps
- before merging or shipping
## Severity levels
- **Blocker**: wrong behavior, security issue, data loss risk, broken tests/build
- **Major**: likely bug, missing edge cases, poor reliability
- **Minor**: style, clarity, small maintainability issues
- **Nit**: optional polish
## Checklist
1. Correctness vs requirements
2. Edge cases & error handling
3. Tests (adequate coverage, meaningful assertions)
4. Security (secrets, auth, injection, unsafe defaults)
5. Performance (obvious hotspots, N+1, unnecessary work)
6. Readability & maintainability
7. Docs / comments updated if needed
## Output format
- Blockers
- Majors
- Minors
- Nits
- Overall summary + next actions

View File

@@ -0,0 +1,30 @@
---
name: superpowers-tdd
description: Applies tests-first discipline (red/green/refactor) and adds regression tests for bugs. Use when implementing features, fixing bugs, or refactoring.
---
# TDD Skill
## When to use this skill
- new features that can be unit tested
- bug fixes (always add a regression test if practical)
- refactors (protect behavior with tests first)
## Rules
- Prefer **red -> green -> refactor**.
- If tests are hard, still add **verification**: minimal repro script, integration test, or clear manual steps.
- Keep tests focused: one behavior per test where possible.
- Name tests by behavior, not implementation details.
## Process
1. Define the behavior change (what should be true after).
2. Write/adjust a test to capture it (make it fail first if possible).
3. Implement the minimal change to pass.
4. Refactor if needed (keep passing).
5. Run the relevant test suite + any linters.
## Output requirements
When you change code, include:
- what tests you added/changed
- how to run them
- what they prove

View File

@@ -0,0 +1,48 @@
---
name: superpowers-workflow
description: Enforces a disciplined workflow for coding, debugging, refactoring, and automation: brainstorm -> plan -> implement with verification (prefer TDD) -> review -> finish. Use for almost any non-trivial change.
---
# Superpowers Workflow
This skill defines the default operating procedure for software and automation tasks.
## When to use this skill
Use whenever the user asks to:
- build or modify code
- debug an error or failing tests
- refactor or improve quality
- design an automation workflow (e.g., API integrations, ETL, pipelines)
- add tests, reliability, or safety checks
## Activation marker (required)
Immediately after reading this skill (before any other output), run:
python .agent/skills/superpowers-workflow/scripts/record_activation.py --skill superpowers-workflow
## Default workflow (mandatory unless explicitly unnecessary)
1. **Brainstorm (short)**: clarify goal, constraints, risks, and acceptance criteria.
2. **Write a plan**: small steps (210 minutes each) with files + verification.
3. **Implement**: make the smallest correct change; prefer tests-first when feasible.
4. **Review pass**: correctness, edge cases, security, style, maintainability.
5. **Finish**: run verification commands, summarize changes + next steps.
## Decision tree: how much process is needed?
- **Tiny change (1 file, obvious)**:
- Do a mini-brainstorm (3 bullets), then mini-plan (35 steps), then implement + verify.
- **Non-trivial change**:
- Full brainstorm + plan before editing.
- **High-risk change** (auth, money, prod data, security, migrations):
- Add explicit risk controls: rollback plan, dry-run, extra tests, logging, safe defaults.
## Output rules (how you communicate)
- Always state **assumptions** if anything is ambiguous.
- Always include **verification** (commands, tests, or observable checks).
- If you must ask questions, ask **at most 3**; then proceed with best assumptions.
## Stop conditions
Pause implementation and switch to planning if:
- requirements conflict
- critical unknowns block correctness
- the change could cause data loss or security issues without safeguards

View File

@@ -0,0 +1,34 @@
from __future__ import annotations
import argparse
from datetime import datetime, timezone
from pathlib import Path
def find_repo_root(start: Path) -> Path:
# Walk upwards until we find a marker that suggests repo root
for p in [start, *start.parents]:
if (p / ".agent").exists() or (p / ".git").exists() or (p / "pyproject.toml").exists():
return p
return start
def main() -> int:
parser = argparse.ArgumentParser()
parser.add_argument("--skill", required=True)
parser.add_argument("--run-id", default="")
args = parser.parse_args()
repo_root = find_repo_root(Path.cwd())
log_path = repo_root / "e2e_demo" / "skill-activation.log"
log_path.parent.mkdir(parents=True, exist_ok=True)
ts = datetime.now(timezone.utc).isoformat()
line = f"{ts}\tskill={args.skill}\trun_id={args.run_id}\n"
log_path.write_text((log_path.read_text() if log_path.exists() else "") + line, encoding="utf-8")
return 0
if __name__ == "__main__":
raise SystemExit(main())

View File

@@ -0,0 +1,245 @@
#!/usr/bin/env python3
"""Spawn an isolated Gemini CLI subagent for focused task execution.
This enables parallel execution by launching independent gemini instances
with isolated context and specific skill instructions.
"""
import argparse
import json
import subprocess
import sys
import time
import uuid
from pathlib import Path
from typing import Any
def find_repo_root(start: Path) -> Path:
"""Traverse upwards to find the repository root (containing .agent/)."""
curr = start.resolve()
for _ in range(10):
if (curr / ".agent").exists():
return curr
if curr.parent == curr:
break
curr = curr.parent
return Path.cwd()
def load_skill_instructions(skill_path: Path) -> str:
"""Load skill instructions from SKILL.md file."""
if not skill_path.exists():
return ""
return skill_path.read_text(encoding="utf-8")
def spawn_subagent(
skill: str,
task: str,
repo_root: Path,
yolo: bool = True,
output_format: str = "text",
) -> dict[str, Any]:
"""
Spawn a subagent with isolated context.
Args:
skill: Skill name (e.g., 'tdd', 'debug', 'review')
task: Task description for the subagent
repo_root: Repository root path
yolo: Auto-approve all actions (default: True for parallel execution)
output_format: Output format ('text' or 'json')
Returns:
dict with keys: success, output, error, log_file, duration_s
"""
# Generate unique subagent ID
subagent_id = uuid.uuid4().hex[:8]
timestamp = time.strftime("%Y%m%d-%H%M%S")
# Setup logging directory
log_dir = repo_root / "artifacts" / "superpowers" / "subagents"
log_dir.mkdir(parents=True, exist_ok=True)
log_file = log_dir / f"{skill}-{timestamp}-{subagent_id}.log"
# Load skill instructions
skill_file = repo_root / f".agent/skills/superpowers-{skill}/SKILL.md"
skill_instructions = load_skill_instructions(skill_file)
if not skill_instructions:
return {
"success": False,
"output": "",
"error": f"Skill not found: {skill_file}",
"log_file": str(log_file),
"duration_s": 0,
}
# Construct focused prompt
prompt = f"""You are a specialized subagent focused on: {skill}
IMPORTANT: You have ISOLATED CONTEXT. Do not assume knowledge from other conversations.
Task:
{task}
Skill Instructions:
{skill_instructions}
Requirements:
1. Follow the skill instructions exactly
2. Complete the task fully
3. Output ONLY the final result at the end
4. Do not include meta-commentary or thinking process in final output
5. Write any artifacts to artifacts/superpowers/subagent-{subagent_id}/
When complete, output:
---SUBAGENT-RESULT-START---
[Your final result here]
---SUBAGENT-RESULT-END---
"""
# Build command
cmd = ["gemini"]
if yolo:
cmd.append("--yolo")
# Execute subagent
start_time = time.time()
try:
with open(log_file, "w", encoding="utf-8") as log:
log.write("=== SUBAGENT EXECUTION LOG ===\n")
log.write(f"Skill: {skill}\n")
log.write(f"ID: {subagent_id}\n")
log.write(f"Timestamp: {timestamp}\n")
log.write(f"Task: {task}\n\n")
log.write("=== PROMPT ===\n")
log.write(prompt)
log.write("\n\n=== EXECUTION ===\n")
log.flush()
result = subprocess.run(
cmd,
input=prompt,
capture_output=True,
text=True,
cwd=repo_root,
timeout=600, # 10 minute timeout
shell=True, # Required on Windows for .ps1/.cmd scripts
)
duration_s = time.time() - start_time
log.write("\n=== STDOUT ===\n")
log.write(result.stdout)
log.write("\n=== STDERR ===\n")
log.write(result.stderr)
log.write(f"\n=== EXIT CODE: {result.returncode} ===\n")
log.write(f"=== DURATION: {duration_s:.2f}s ===\n")
# Extract final result from markers
output = result.stdout
if "---SUBAGENT-RESULT-START---" in output:
parts = output.split("---SUBAGENT-RESULT-START---", 1)
if len(parts) > 1:
result_part = parts[1].split("---SUBAGENT-RESULT-END---", 1)
output = result_part[0].strip()
return {
"success": result.returncode == 0,
"output": output,
"error": result.stderr if result.returncode != 0 else "",
"log_file": str(log_file),
"duration_s": duration_s,
"subagent_id": subagent_id,
}
except subprocess.TimeoutExpired:
duration_s = time.time() - start_time
return {
"success": False,
"output": "",
"error": f"Subagent timed out after {duration_s:.0f}s",
"log_file": str(log_file),
"duration_s": duration_s,
"subagent_id": subagent_id,
}
except Exception as e:
duration_s = time.time() - start_time
return {
"success": False,
"output": "",
"error": f"Subagent execution failed: {e}",
"log_file": str(log_file),
"duration_s": duration_s,
"subagent_id": subagent_id,
}
def main() -> int:
parser = argparse.ArgumentParser(
description="Spawn a Gemini CLI subagent for parallel execution"
)
parser.add_argument(
"--skill",
required=True,
help="Skill to use (tdd, debug, review, rest-automation, python-automation)",
)
parser.add_argument(
"--task",
required=True,
help="Task description for the subagent",
)
parser.add_argument(
"--no-yolo",
action="store_true",
help="Disable auto-approval (interactive mode)",
)
parser.add_argument(
"--output-format",
choices=["text", "json"],
default="text",
help="Output format",
)
args = parser.parse_args()
repo_root = find_repo_root(Path.cwd())
if args.output_format == "text":
print(f"🤖 Spawning subagent: {args.skill}")
print(f"📋 Task: {args.task[:80]}{'...' if len(args.task) > 80 else ''}")
result = spawn_subagent(
skill=args.skill,
task=args.task,
repo_root=repo_root,
yolo=not args.no_yolo,
output_format=args.output_format,
)
if args.output_format == "json":
print(json.dumps(result, indent=2))
return 0 if result["success"] else 1
# Text output
print(f"\n{'' if result['success'] else ''} Subagent completed in {result['duration_s']:.1f}s")
print(f"📝 Full log: {result['log_file']}")
if result["success"]:
print(f"\n{'='*60}")
print("RESULT:")
print(f"{'='*60}")
print(result["output"])
return 0
else:
print(f"\n{'='*60}")
print("ERROR:")
print(f"{'='*60}")
print(result["error"])
return 1
if __name__ == "__main__":
raise SystemExit(main())

View File

@@ -0,0 +1,28 @@
from __future__ import annotations
import argparse
import sys
from pathlib import Path
def find_repo_root(start: Path) -> Path:
for p in [start, *start.parents]:
if (p / ".agent").exists() or (p / ".git").exists():
return p
return start
def main() -> int:
parser = argparse.ArgumentParser()
parser.add_argument("--path", required=True, help="Repo-relative path to write, e.g. artifacts/superpowers/brainstorm.md")
args = parser.parse_args()
repo_root = find_repo_root(Path.cwd())
out_path = (repo_root / args.path).resolve()
out_path.parent.mkdir(parents=True, exist_ok=True)
content = sys.stdin.read()
out_path.write_text(content, encoding="utf-8")
print(str(out_path))
return 0
if __name__ == "__main__":
raise SystemExit(main())

View File

@@ -0,0 +1,38 @@
---
description: Superpowers brainstorm. Produces goal/constraints/risks/options/recommendation/acceptance criteria.
---
# Superpowers Brainstorm
## Task
Brainstorm for this task (exactly as provided by the user):
**{{input}}**
If `{{input}}` is empty or missing, ask the user to restate the task in one sentence and STOP.
## Output sections (use exactly)
## Goal
## Constraints
## Known context
## Risks
## Options (24)
## Recommendation
## Acceptance criteria
## Persist (mandatory)
After generating the brainstorm content, you MUST write it to disk using this exact procedure:
1) Output the brainstorm markdown content first (the sections above).
2) Then immediately run:
```bash
python .agent/skills/superpowers-workflow/scripts/write_artifact.py --path artifacts/superpowers/brainstorm.md
```
Provide the brainstorm markdown as stdin to the command.
After writing, confirm it exists by listing artifacts/superpowers/.
If you cannot run the command, say so explicitly and instruct the user to copy/paste the brainstorm output into artifacts/superpowers/brainstorm.md.
Do not implement changes in this workflow. Stop after persistence.

View File

@@ -0,0 +1,33 @@
---
description: Systematic debugging workflow: reproduce, minimize, hypotheses, instrument, fix, prevent, verify.
---
# Superpowers Debug
Read and apply the `superpowers-debug` skill.
Use the required reporting format:
- Symptom
- Repro steps
- Root cause
- Fix
- Regression protection
- Verification
## Persist (mandatory)
After generating the debug content above, you MUST write it to disk:
1) Copy the full debug markdown output.
2) Run:
```bash
python .agent/skills/superpowers-workflow/scripts/write_artifact.py --path artifacts/superpowers/debug.md
```
Provide the debug markdown as stdin to the command.
After writing, confirm it exists by listing artifacts/superpowers/.
If you cannot run the command, say so explicitly and instruct the user to copy/paste the debug output into artifacts/superpowers/debug.md.
Do not implement changes in this workflow. Stop after persistence.

View File

@@ -0,0 +1,213 @@
---
description: Execute an approved plan with parallel execution for independent steps. Spawns isolated subagents. Consolidates results.
---
# Superpowers Execute Plan (Parallel Mode)
## Overview
This workflow executes an approved plan by identifying independent steps and running them in parallel using isolated subagents.
## When to use parallel mode
- Plan has 2+ steps that don't depend on each other
- Steps operate on different files or independent modules
- You want faster execution (parallel > sequential)
## When NOT to use parallel mode
- Steps have dependencies (Step 2 needs Step 1's output)
- All steps modify the same file
- Plan has < 2 steps
- You want simpler debugging (sequential is easier to debug)
**If unsure, use `/superpowers-execute-plan` (sequential) instead.**
---
## Preconditions (do not skip)
1. The user must have replied **APPROVED** to a written plan
2. The approved plan must exist at: `artifacts/superpowers/plan.md`
If `artifacts/superpowers/plan.md` does not exist:
- Stop immediately
- Tell the user to run `/superpowers-write-plan` first
- Do not continue
---
## Load and analyze the plan
1. Read `artifacts/superpowers/plan.md`
2. Parse all plan steps
3. Identify dependencies between steps:
- Does Step 2 modify files created/changed by Step 1?
- Does Step 2 need Step 1's verification to pass first?
- Do they modify the same files?
4. Group steps into execution batches:
- **Batch 1**: All independent steps (no dependencies)
- **Batch 2**: Steps that depend on Batch 1 completing
- **Batch 3**: Steps that depend on Batch 2 completing
- etc.
---
## Execution strategy
### For each batch:
1. **Spawn subagents in parallel** for all steps in the batch:
```bash
# Example: Batch 1 has 3 independent steps
python .agent/skills/superpowers-workflow/scripts/spawn_subagent.py \
--skill tdd \
--task "Step 1: Add retry logic to sync.py with exponential backoff" &
python .agent/skills/superpowers-workflow/scripts/spawn_subagent.py \
--skill rest-automation \
--task "Step 2: Add pagination handling to fetch_items()" &
python .agent/skills/superpowers-workflow/scripts/spawn_subagent.py \
--skill python-automation \
--task "Step 3: Update CLI args to support --max-retries flag" &
# Wait for all to complete
wait
```
2. **Collect results** from each subagent:
- Check log files in `artifacts/superpowers/subagents/`
- Extract final results from each
- Check success/failure status
3. **Verify batch completion**:
- Run verification commands for all steps in the batch
- If ANY step fails:
- Stop execution
- Switch to `/superpowers-debug` for the failed step
- Do NOT continue to next batch
4. **Append to execution log**:
- Write batch summary to `artifacts/superpowers/execution.md`:
```markdown
## Batch N (Parallel Execution)
- Step X: [SUCCESS/FAILED] - Files: [...] - Duration: Xs
- Step Y: [SUCCESS/FAILED] - Files: [...] - Duration: Ys
Verification:
- Step X: [command] -> [result]
- Step Y: [command] -> [result]
```
5. **Move to next batch** (if all steps passed)
---
## Skill selection for subagents
Choose the appropriate skill for each step:
| Step Type | Skill to Use |
|-----------|-------------|
| Add tests, TDD cycle | `tdd` |
| Fix bugs, investigate failures | `debug` |
| Code review, quality check | `review` |
| REST API work | `rest-automation` |
| Python tooling/scripts | `python-automation` |
| General implementation | `tdd` (default) |
---
## Consolidation phase
After all batches complete:
1. **Integration verification**:
- Run full test suite (not just individual step tests)
- Verify all changes work together
- Check for conflicts between parallel changes
2. **Conflict resolution**:
- If parallel steps modified related code:
- Review for integration issues
- Run combined tests
- Fix any conflicts
3. **Final artifacts**:
- Update `artifacts/superpowers/execution.md` with:
- Total batches executed
- Total steps completed
- Total time saved vs sequential
- All verification results
- Write `artifacts/superpowers/finish.md` with:
- Summary of changes
- Integration test results
- Follow-up items (if any)
---
## Example: 5-step plan with 2 batches
**Plan:**
1. Add retry logic to sync.py (independent)
2. Add pagination to API client (independent)
3. Update CLI args (independent)
4. Add integration test (depends on 1, 2, 3)
5. Update docs (depends on 4 passing)
**Execution:**
**Batch 1 (parallel):**
- Spawn 3 subagents for steps 1, 2, 3
- Wait for all to complete (~5 min instead of ~15 min sequential)
- Verify each step
**Batch 2 (sequential):**
- Step 4: Add integration test (needs 1+2+3 complete)
- Verify test passes
**Batch 3 (sequential):**
- Step 5: Update docs (needs 4 complete)
- Verify docs are accurate
**Total time: ~10 min vs ~25 min sequential = 60% time savings**
---
## Troubleshooting
### Subagent spawn fails
- Check that `gemini` is in PATH (verify with: `gemini --version`)
- Verify skill exists: `.agent/skills/superpowers-{skill}/SKILL.md`
- Check subagent logs in `artifacts/superpowers/subagents/`
### Steps conflict
- Falls back to sequential execution for conflicting steps
- Mark dependent steps explicitly in plan to avoid conflicts
### Verification fails after parallel execution
- Check integration - parallel steps may work individually but conflict
- Run `/superpowers-debug` to investigate
- Consider re-running in sequential mode: `/superpowers-execute-plan`
---
## Persist (mandatory)
Write execution notes to disk:
- Append batch summaries to: `artifacts/superpowers/execution.md`
- Write final summary to: `artifacts/superpowers/finish.md`
Ensure `artifacts/superpowers/` exists.
Confirm files exist by listing `artifacts/superpowers/` when done.
---
## Finish
After all steps complete:
1. Run `/superpowers-review` (or inline review pass)
2. Generate final summary with time savings metrics
3. List all changed files
4. Provide any manual validation steps
Stop after completing the finish step.

View File

@@ -0,0 +1,84 @@
---
description: Executes an approved plan in small steps with verification after each step. Writes execution artifacts to disk. Stops on failures. Finishes with review + summary.
---
# Superpowers Execute Plan
## Persist (mandatory)
You must write execution artifacts to disk (not IDE-only documents):
- Append execution notes to: `artifacts/superpowers/execution.md`
- Write the final summary to: `artifacts/superpowers/finish.md`
Requirements:
1) Ensure the folder `artifacts/superpowers/` exists (create it if needed).
2) After EACH completed plan step, append a note to `artifacts/superpowers/execution.md`.
3) At the end, write the final summary to `artifacts/superpowers/finish.md`.
4) After writing, confirm the files exist by listing `artifacts/superpowers/`.
If you are unable to write these files directly, use `python .agent/skills/superpowers-workflow/scripts/write_artifact.py --path <target>` to persist the content.
## Preconditions (do not skip)
1) The user must have replied **APPROVED** to a written plan.
2) The approved plan must exist on disk at:
- `artifacts/superpowers/plan.md`
If `artifacts/superpowers/plan.md` does not exist:
- Stop immediately.
- Tell the user to run `/superpowers-write-plan` first.
- Do not edit code.
## Load the plan
- Read `artifacts/superpowers/plan.md`.
- Restate the plan briefly (12 lines) before making changes.
## Check for parallel execution opportunity (optional)
After loading the plan, analyze if steps can run in parallel:
1. **Check for independent steps**: Do 2+ steps operate on different files with no dependencies?
2. **If yes**: Suggest to the user:
- "I notice steps X, Y, Z are independent and could run in parallel."
- "Would you like to use `/superpowers-execute-plan-parallel` for faster execution?"
- "Or continue with sequential execution? (Reply: PARALLEL or SEQUENTIAL)"
3. **If PARALLEL**: Stop and instruct user to run `/superpowers-execute-plan-parallel` instead.
4. **If SEQUENTIAL or no independent steps**: Continue with sequential execution below.
## Skills to apply as needed
Read and apply these skills when relevant:
- `superpowers-tdd` (preferred)
- `superpowers-debug` (if issues occur)
- `superpowers-review`
- `superpowers-finish`
- `superpowers-rest-automation` (if relevant)
- `superpowers-python-automation` (if Python)
## Execution rules (strict)
1) Implement **ONE** plan step at a time.
2) After each step:
- Run the steps verification command(s) (or, if you cannot run them, provide exact commands and expected outcomes).
- Append a short note to `artifacts/superpowers/execution.md` containing:
- Step name
- Files changed
- What changed (13 bullets)
- Verification command(s)
- Result (pass/fail or “not run”)
3) If verification fails:
- Stop.
- Switch to systematic debugging (use `superpowers-debug`).
- Do not continue executing further steps until fixed and verified.
4) Keep changes minimal and scoped to the plan. If the plan is wrong or missing a step:
- Stop and update the plan (write the updated plan back to `artifacts/superpowers/plan.md`)
- Ask for approval again if the change is material.
## Finish (required)
At the end:
1) Run a review pass (Blocker/Major/Minor/Nit).
2) Write a final summary to `artifacts/superpowers/finish.md` including:
- Verification commands run + results
- Summary of changes
- Follow-ups (if any)
- Manual validation steps (if applicable)
3) Confirm the artifacts exist by listing `artifacts/superpowers/`.
Stop after completing the finish step.

View File

@@ -0,0 +1,31 @@
---
description: Finalize work: verification, summary, follow-ups, manual validation steps.
---
# Superpowers Finish
Read and apply the `superpowers-finish` skill.
Output:
## Verification (commands + results if possible)
## Summary of changes
## Follow-ups (if needed)
## Manual validation steps (if applicable)
## Persist (mandatory)
After generating the finish content above, you MUST write it to disk:
1) Copy the full finish markdown output.
2) Run:
```bash
python .agent/skills/superpowers-workflow/scripts/write_artifact.py --path artifacts/superpowers/finish.md
```
Provide the finish markdown as stdin to the command.
After writing, confirm it exists by listing artifacts/superpowers/.
If you cannot run the command, say so explicitly and instruct the user to copy/paste the finish output into artifacts/superpowers/finish.md.
Do not implement changes in this workflow. Stop after persistence.

View File

@@ -0,0 +1,13 @@
---
description: Reloads Superpowers configuration by re-reading Rules, Workflows, and Skills from disk.
---
# Superpowers Reload
Read these directories from disk and summarize what you loaded:
- `.agent/rules/`
- `.agent/workflows/`
- `.agent/skills/` (list skill names + descriptions)
Then confirm you will follow the latest versions in this session.
Stop after confirming.

View File

@@ -0,0 +1,32 @@
---
description: Runs a Superpowers-style review pass with severity levels.
---
# Superpowers Review
Read and apply the `superpowers-review` skill.
Output:
- Blockers
- Majors
- Minors
- Nits
- Summary + next actions
## Persist (mandatory)
After generating the review content above, you MUST write it to disk:
1) Copy the full review markdown output.
2) Run:
```bash
python .agent/skills/superpowers-workflow/scripts/write_artifact.py --path artifacts/superpowers/review.md
```
Provide the review markdown as stdin to the command.
After writing, confirm it exists by listing artifacts/superpowers/.
If you cannot run the command, say so explicitly and instruct the user to copy/paste the review output into artifacts/superpowers/review.md.
Do not implement changes in this workflow. Stop after persistence.

View File

@@ -0,0 +1,57 @@
---
description: Superpowers plan gate. Writes a small-step plan with files + verification. Must ask for approval before coding.
---
# Superpowers Write Plan (Gate)
## Task
Plan for this task (exactly as provided by the user):
**{{input}}**
If `{{input}}` is empty or missing, ask the user to restate the task in one sentence and STOP.
## Rules
- DO NOT edit code.
- You may read files to understand context, but produce the plan and then stop.
- Plan steps must be small (210 minutes each) and include verification commands.
## Output format (use exactly)
## Goal
## Assumptions
## Plan
(Each step must include: Files, Change, Verify)
## Risks & mitigations
## Rollback plan
## Persist (mandatory)
Write the plan output to:
- `artifacts/superpowers/plan.md`
Create the folder if needed.
After writing, confirm it exists by listing `artifacts/superpowers/`.
## Approval
Ask:
**Approve this plan? Reply APPROVED if it looks good.**
If the user replies APPROVED:
- Do NOT implement yet.
- Reply: **"Plan approved. Run `/superpowers-execute-plan` to begin implementation."**
## Persist (mandatory)
After generating the plan content above, you MUST write it to disk:
1) Copy the full plan markdown output.
2) Run:
```bash
python .agent/skills/superpowers-workflow/scripts/write_artifact.py --path artifacts/superpowers/plan.md
```
Provide the plan markdown as stdin to the command.
After writing, confirm it exists by listing artifacts/superpowers/.
If you cannot run the command, say so explicitly and instruct the user to copy/paste the plan output into artifacts/superpowers/plan.md.
Do not implement changes in this workflow. Stop after persistence.

View File

@@ -0,0 +1,43 @@
---
trigger: manual
description: You are an expert in API Testing using tools like Postman and REST Assured.
---
# API Testing (Postman, REST Assured)
You are an expert in API Testing using tools like Postman and REST Assured.
Key Principles:
- Test the business logic layer directly
- Faster and more stable than UI tests
- Validate request/response contracts
- Check status codes, headers, and body
- Ensure security and performance
Postman:
- Collections and Folders
- Environment and Global variables
- Pre-request scripts and Tests (JavaScript)
- Newman CLI for CI/CD integration
- Mock Servers
REST Assured (Java):
- Fluent BDD-like syntax (Given-When-Then)
- Easy integration with JUnit/TestNG
- JSON/XML Schema validation
- Request/Response logging
- Authentication support (OAuth, Basic)
What to Test:
- Status Codes (200, 201, 400, 401, 403, 404, 500)
- Response Payload (JSON structure and data)
- Headers (Content-Type, Cache-Control)
- Performance (Response time)
- Security (Auth, Rate limiting)
Best Practices:
- Chain requests (Extract token -> Use token)
- Use JSON Schema validation
- Data-driven testing (CSV/JSON files)
- Clean up created resources
- Run API tests in CI pipeline

View File

@@ -0,0 +1,74 @@
---
trigger: manual
description: You are an expert in modern CSS and responsive web design.
---
# Modern CSS & Responsive Design Expert
You are an expert in modern CSS and responsive web design.
Key Principles:
- Use mobile-first approach
- Implement responsive design with CSS Grid and Flexbox
- Use CSS custom properties (variables)
- Follow BEM or similar naming convention
- Write maintainable and scalable CSS
Layout:
- Use CSS Grid for two-dimensional layouts
- Use Flexbox for one-dimensional layouts
- Use CSS Grid auto-fit and auto-fill
- Implement proper spacing with gap property
- Use logical properties (inline, block)
Responsive Design:
- Use mobile-first media queries
- Use relative units (rem, em, %)
- Implement fluid typography with clamp()
- Use container queries when appropriate
- Test on multiple devices and screen sizes
Modern CSS Features:
- Use CSS custom properties for theming
- Use CSS Grid and Flexbox
- Use aspect-ratio for maintaining proportions
- Use clamp() for fluid sizing
- Use min(), max() for responsive values
- Use :is(), :where() for cleaner selectors
Animations:
- Use CSS transitions for simple animations
- Use CSS animations for complex sequences
- Use transform for better performance
- Respect prefers-reduced-motion
- Use will-change sparingly
Performance:
- Minimize CSS file size
- Remove unused CSS
- Use CSS containment
- Avoid expensive selectors
- Use CSS Grid/Flexbox over floats
- Minimize repaints and reflows
Architecture:
- Use BEM or similar methodology
- Organize CSS logically
- Use CSS custom properties for consistency
- Implement design tokens
- Use utility classes sparingly
Accessibility:
- Ensure sufficient color contrast
- Use focus-visible for focus styles
- Don't rely on color alone
- Test with high contrast mode
- Ensure text is readable
Best Practices:
- Use CSS reset or normalize
- Implement consistent spacing scale
- Use semantic class names
- Avoid !important
- Comment complex CSS
- Use CSS linting tools

View File

@@ -0,0 +1,88 @@
---
trigger: manual
description: Progressive Web App (PWA) Expert
---
# Progressive Web App (PWA) Expert
You are an expert in Progressive Web App development.
Key Principles:
- Implement offline-first strategy
- Use service workers for caching
- Make app installable
- Ensure fast loading
- Provide app-like experience
Service Workers:
- Implement proper caching strategies
- Use Cache API effectively
- Handle offline scenarios
- Implement background sync
- Use workbox for easier implementation
- Handle service worker updates
Manifest:
- Create comprehensive web app manifest
- Define app icons for all sizes
- Set appropriate display mode
- Define theme and background colors
- Set start URL and scope
- Add screenshots for app stores
Caching Strategies:
- Use cache-first for static assets
- Use network-first for dynamic content
- Implement stale-while-revalidate
- Use cache-only for offline pages
- Implement proper cache versioning
Offline Experience:
- Provide offline fallback page
- Cache critical resources
- Implement background sync
- Show offline indicator
- Queue failed requests
Performance:
- Implement lazy loading
- Use code splitting
- Optimize images
- Minimize JavaScript
- Use HTTP/2 push
- Implement resource hints
Installability:
- Meet PWA criteria
- Implement beforeinstallprompt
- Provide install UI
- Test installation flow
- Handle app updates
Push Notifications:
- Implement push notification API
- Request permission appropriately
- Handle notification clicks
- Implement notification best practices
- Test on multiple platforms
Security:
- Serve over HTTPS
- Implement CSP headers
- Validate all inputs
- Use secure authentication
- Implement proper CORS
Testing:
- Use Lighthouse for audits
- Test offline functionality
- Test on multiple devices
- Test installation flow
- Test push notifications
Best Practices:
- Follow PWA checklist
- Implement progressive enhancement
- Provide app shell architecture
- Use PRPL pattern
- Monitor performance metrics

View File

@@ -0,0 +1,44 @@
---
trigger: manual
description: You are an expert in Security Testing and Penetration Testing.
---
# Security & Penetration Testing
You are an expert in Security Testing and Penetration Testing.
Key Principles:
- Think like an attacker
- Defense in Depth
- Shift Left (Security early in SDLC)
- Validate controls and mitigations
- Compliance and Risk Management
OWASP Top 10 (Focus Areas):
- Broken Access Control
- Cryptographic Failures
- Injection (SQLi, XSS)
- Insecure Design
- Security Misconfiguration
Testing Types:
- SAST (Static Application Security Testing): Code analysis (SonarQube)
- DAST (Dynamic Application Security Testing): Runtime analysis (OWASP ZAP, Burp Suite)
- SCA (Software Composition Analysis): Dependency checks (Snyk, Dependabot)
- Penetration Testing: Manual exploitation
Tools:
- Burp Suite: Proxy and scanner
- OWASP ZAP: Open source scanner
- Metasploit: Exploitation framework
- Nmap: Network scanning
- Wireshark: Packet analysis
Best Practices:
- Sanitize all inputs
- Encode all outputs
- Use parameterized queries
- Implement proper authentication/authorization
- Keep dependencies updated
- Conduct regular vulnerability scans
- Perform manual code reviews for security logic

View File

@@ -0,0 +1,25 @@
{
"permissions": {
"allow": [
"mcp__plugin_context-mode_context-mode__ctx_batch_execute",
"mcp__plugin_context-mode_context-mode__ctx_search",
"Bash(git add:*)",
"Bash(git commit -m ':*)",
"mcp__plugin_context-mode_context-mode__ctx_execute",
"Bash(git commit -m 'docs: update SESSION_STATE cu status [C-01] JWT auth COMPLET:*)",
"Bash(git commit -m 'docs: final SESSION_STATE — ALL TASKS COMPLETE v1.3.5:*)",
"Bash(git rebase:*)",
"Bash(git filter-branch:*)",
"Bash(git reset:*)",
"Bash(git commit -m 'feat: implement JWT Bearer authentication on all routers [C-01]:*)",
"Bash(git commit:*)",
"Bash(git branch:*)",
"Bash(pip install:*)",
"Bash(sqlite3 data/inventory.db \"SELECT username, role, origin, hashed_password FROM users;\")",
"Bash(sqlite3 data/inventory.db \".schema users\")",
"Bash(sqlite3 data/inventory.db \"SELECT * FROM users;\")",
"Bash(git restore:*)",
"Bash(pkill -f \"uvicorn\")"
]
}
}

95
.gitignore vendored
View File

@@ -1,10 +1,91 @@
# ============================================================
# TFM aInventory — .gitignore
# ============================================================
# ── Python environments ──────────────────────────────────────
.venv/
backend/venv/
backend/data/
__pycache__/
**/__pycache__/
*.pyc
.env
.DS_Store
aInventory-PROD*
aInventory-PROD*.zip
logs/
*.pyo
*.pyd
*.egg-info/
dist/
build/
# ── Runtime data directories ─────────────────────────────────
# Content is excluded; the directories themselves are tracked via .gitkeep.
# On fresh clone: run ./start_server.sh or docker compose up to initialize.
/data/*
!/data/.gitkeep
/data/backups/
/logs/*
!/logs/.gitkeep
# Duplicate runtime dirs that may exist inside backend/ (Docker legacy)
backend/data/
backend/logs/
# ── Sensitive configuration files ────────────────────────────
# The ACTIVE LDAP config is: backend/config/ldap_config.json
# It contains real server IPs and credentials — never commit.
# The template/example IS committed and used by init_data.sh on fresh installs.
backend/config/ldap_config.json
!backend/config/ldap_config.json.example
# ── Environment files (secrets) ──────────────────────────────
.env
.env.*
!.env.example
backend/.env
backend/.env.*
!backend/.env.example
# Docker environment override file
docker-compose.override.yml
.env.docker
# ── Application logs ─────────────────────────────────────────
# (also covered by /logs/* above, these catch any other locations)
frontend/logs/
*.log
npm-debug.log*
yarn-debug.log*
yarn-error.log*
# ── Frontend build artifacts ──────────────────────────────────
frontend/.next/
frontend/out/
frontend/build/
frontend/node_modules/
# ── Frontend generated/runtime assets ────────────────────────
# SSL certs and runtime configs (generated by start_server.sh)
frontend/config/
# PWA icons generated at build time
frontend/public/icons/
# ── npm / npx caches ─────────────────────────────────────────
.npx_cache/
scratch/npm_cache/
# ── Production bundles (generated by export_prod.sh) ─────────
aInventory-PROD*/
aInventory-PROD*.zip
# ── AI / IDE metadata ─────────────────────────────────────────
.remember/
.claude/
# ── macOS system files ────────────────────────────────────────
.DS_Store
**/.DS_Store
# ── Certificates & keys ──────────────────────────────────────
*.pem
*.key
*.crt
*.cert
__push_ALL_to_remote.sh

Some files were not shown because too many files have changed in this diff Show More