chore: refactor agent configurations and update testing instructions

- Updated QA Security agent to use GPT-5.2-Codex and expanded toolset for enhanced functionality. - Revised Supervisor agent to utilize GPT-5.2-Codex and improved toolset for code review processes. - Modified architecture instructions to specify running Playwright tests with Firefox. - Adjusted copilot instructions to run Playwright tests with Firefox as the default browser. - Created documentation for coding best practices to ensure consistency and quality in project documentation. - Established HTML/CSS style color guide to maintain accessible and professional design standards. - Updated Playwright TypeScript instructions to reflect the change in default browser to Firefox. - Enhanced testing instructions to clarify integration testing processes and default browser settings. - Updated integration test scripts to align with CI workflows and improve clarity in execution. - Created new integration test scripts for Cerberus, rate limiting, and WAF functionalities. - Adjusted E2E testing scripts to default to Firefox and updated documentation accordingly. - Modified GitHub Actions workflow to run the comprehensive integration test suite.
2026-02-07 06:33:14 +00:00
parent 10582872f9
commit eb23148845
30 changed files with 630 additions and 111 deletions
@@ -970,7 +970,7 @@ Closes #123
 **Execution:**
 ```bash
 # Run against Docker container
-npx playwright test --project=chromium
+cd /projects/Charon npx playwright test --project=firefox

 # Run with coverage (Vite dev server)
 .github/skills/scripts/skill-runner.sh test-e2e-playwright-coverage
@@ -128,7 +128,7 @@ Before proposing ANY code change or fix, you must build a mental map of the feat
 Before marking an implementation task as complete, perform the following in order:

 1. **Playwright E2E Tests** (MANDATORY - Run First):
-    - **Run**: `npx playwright test --project=chromium` from project root
+    - **Run**: `cd /projects/Charon npx playwright test --project=firefox` from project root
    - **Why First**: If the app is broken at E2E level, unit tests may need updates. Catch integration issues early.
    - **Scope**: Run tests relevant to modified features (e.g., `tests/manual-dns-provider.spec.ts`)
    - **On Failure**: Trace root cause through frontend → backend flow before proceeding
@@ -0,0 +1,43 @@
+---
+description: This file describes the documentation and coding best practices for the project.
+applyTo: '*'
+---
+
+
+# Documentation & Coding Best Practices
+
+The following instructions govern how you should generate and update documentation and code. These rules are absolute.
+
+## 1. Zero-Footprint Attribution (The Ghostwriter Rule)
+* **No AI Branding:** You are a ghostwriter. You must **NEVER** add sections titled "AI Notes," "Generated by," "Model Commentary," or "LLM Analysis."
+* **Invisible Editing:** The documentation must appear as if written 100% by the project maintainer. Do not leave "scars" or meta-tags indicating an AI touched the file.
+* **The "Author" Field:** * **Existing Files:** NEVER modify an existing `Author` field.
+    * **New Files:** Do NOT add an `Author` field unless explicitly requested.
+    * **Strict Prohibition:** You are strictly forbidden from placing "GitHub Copilot," "AI," "Assistant," or your model name in any `Author`, `Credits`, or `Contributor` field.
+
+## 2. Documentation Style
+* **Direct & Professional:** The documentation itself is the "note." Do not add a separate preamble or postscript explaining what you wrote.
+* **No Conversational Filler:** When asked to generate documentation, output *only* the documentation content. Do not wrap it in "Here is the updated file:" or "I have added the following..."
+* **Maintenance:** When updating a file, respect the existing formatting style (headers, indentation, bullet points) perfectly. Do not "fix" style choices unless they are actual syntax errors.
+* **Consistency:** Follow the existing style of the file. If the file uses a specific format for sections, maintain that format. Do not introduce new formatting styles.
+* **Clarity & Brevity:** Be concise and clear. Avoid unnecessary verbosity or overly technical jargon unless the file's existing style is already very technical. Match the tone and complexity of the existing documentation.
+
+## 3. Interaction Constraints
+* **Calm & Concise:** Be succinct. Do not offer unsolicited advice or "bonus" refactoring unless it is critical for security.
+* **Context Retention:** Assume the user knows what they are doing. Do not explain basic concepts unless asked.
+* **No Code Generation in Documentation Files:** When editing documentation files, do not generate code snippets unless they are explicitly requested. Focus on the documentation content itself.
+* **No Meta-Comments:** Do not include comments about the editing process, your thought process, or any "notes to self" in the documentation. The output should be clean and ready for use.
+* **Respect User Intent:** If the user asks for a specific change, do only that change. Do not add additional edits or improvements unless they are critical for security or correctness.
+* **No "Best Practices" Sections:** Do not add sections titled "Best Practices," "Recommendations," or "Guidelines" unless the existing file already has such a section. If the file does not have such a section, do not create one.
+* **No "Next Steps" or "Further Reading":** Do not add sections that suggest next steps, further reading, or related topics unless the existing file already includes such sections.
+* **No Personalization:** Do not personalize the documentation with phrases like "As a developer, you should..." or "In this project, we recommend..." Keep the tone neutral and professional.
+* **No Apologies or Uncertainty:** Do not include phrases like "I hope this helps," "Sorry for the confusion," or "Please let me know if you have any questions." The documentation should be authoritative and confident.
+* **No Redundant Information:** Do not include information that is already clearly stated in the existing documentation. Avoid redundancy.
+* **No Unsolicited Refactoring:** Do not refactor existing documentation for style or clarity unless it contains critical errors. Focus on the specific changes requested by the user.
+* **No "Summary" or "Overview" Sections:** Do not add summary or overview sections unless the existing file already has them. If the file does not have such sections, do not create them.
+* **No "How It Works" Sections:** Do not add sections explaining how the code works unless the existing documentation already includes such sections. If the file does not have such sections, do not create them.
+* **No "Use Cases" or "Examples":** Do not add use cases, examples, or case studies unless the existing documentation already has such sections. If the file does not have such sections, do not create them.
+* **No "Troubleshooting" Sections:** Do not add troubleshooting sections unless the existing documentation already includes them. Toubleshooting is its own section of the docs and should not be added ad-hoc to unrelated files.
+* **No "FAQ" Sections:** Do not add FAQ sections unless the existing documentation already has them. If the file does not have such sections, do not create them.
+* **No "Contact" or "Support" Sections:** Do not add contact information, support channels, or similar sections unless the existing documentation already includes them. If the file does not have such sections, do not create them.
+* **No "Contributing" Sections:** Contributing has its on documentation file. Do not add contributing guidelines to unrelated documentation files unless they already have such sections.
@@ -0,0 +1,104 @@
+---
+description: 'Color usage guidelines and styling rules for HTML elements to ensure accessible, professional designs.'
+applyTo: '**/*.html, **/*.css, **/*.js'
+---
+
+# HTML CSS Style Color Guide
+
+Follow these guidelines when updating or creating HTML/CSS styles for browser rendering. Color names
+represent the full spectrum of their respective hue ranges (e.g., "blue" includes navy, sky blue, etc.).
+
+## Color Definitions
+
+- **Hot Colors**: Oranges, reds, and yellows
+- **Cool Colors**: Blues, greens, and purples
+- **Neutral Colors**: Grays and grayscale variations
+- **Binary Colors**: Black and white
+- **60-30-10 Rule**
+  - **Primary Color**: Use 60% of the time (*cool or light color*)
+  - **Secondary Color**: Use 30% of the time (*cool or light color*)
+  - **Accent**: Use 10% of the time (*complementary hot color*)
+
+## Color Usage Guidelines
+
+Balance the colors used by applying the **60-30-10 rule** to graphic design elements like backgrounds,
+buttons, cards, etc...
+
+### Background Colors
+
+**Never Use:**
+
+- Purple or magenta
+- Red, orange, or yellow
+- Pink
+- Any hot color
+
+**Recommended:**
+
+- White or off-white
+- Light cool colors (e.g., light blues, light greens)
+- Subtle neutral tones
+- Light gradients with minimal color shift
+
+### Text Colors
+
+**Never Use:**
+
+- Yellow (poor contrast and readability)
+- Pink
+- Pure white or light text on light backgrounds
+- Pure black or dark text on dark backgrounds
+
+**Recommended:**
+
+- Dark neutral colors (e.g., #1f2328, #24292f)
+- Near-black variations (#000000 to #333333)
+  - Ensure background is a light color
+- Dark grays (#4d4d4d, #6c757d)
+- High-contrast combinations for accessibility
+- Near-white variations (#ffffff to #f0f2f3)
+  - Ensure background is a dark color
+
+### Colors to Avoid
+
+Unless explicitly required by design specifications or user request, avoid:
+
+- Bright purples and magentas
+- Bright pinks and neon colors
+- Highly saturated hot colors
+- Colors with low contrast ratios (fails WCAG accessibility standards)
+
+### Colors to Use Sparingly
+
+**Hot Colors** (red, orange, yellow):
+
+- Reserve for critical alerts, warnings, or error messages
+- Use only when conveying urgency or importance
+- Limit to small accent areas rather than large sections
+- Consider alternatives like icons or bold text before using hot colors
+
+## Gradients
+
+Apply gradients with subtle color transitions to maintain professional aesthetics.
+
+### Best Practices
+
+- Keep color shifts minimal (e.g., #E6F2FF to #F5F7FA)
+- Use gradients within the same color family
+- Avoid combining hot and cool colors in a single gradient
+- Prefer linear gradients over radial for backgrounds
+
+### Appropriate Use Cases
+
+- Background containers and sections
+- Button hover states and interactive elements
+- Drop shadows and depth effects
+- Header and navigation bars
+- Card components and panels
+
+## Additional Resources
+
+- [Color Tool](https://civicactions.github.io/uswds-color-tool/)
+- [Government or Professional Color Standards](https://designsystem.digital.gov/design-tokens/color/overview/)
+- [UI Color Palette Best Practices](https://www.interaction-design.org/literature/article/ui-color-palette)
+- [Color Combination Resource](https://www.figma.com/resource-library/color-combinations/)
@@ -70,7 +70,7 @@ test.describe('Movie Search Feature', () => {

 ## Test Execution Strategy

-1. **Initial Run**: Execute tests with `npx playwright test --project=chromium`
+1. **Initial Run**: Execute tests with `cd /projects/Charon npx playwright test --project=firefox`
 2. **Debug Failures**: Analyze test failures and identify root causes
 3. **Iterate**: Refine locators, assertions, or test logic as needed
 4. **Validate**: Ensure tests pass consistently and cover the intended functionality
@@ -35,6 +35,7 @@ This step:
 - Ensure forms submit correctly
 - Check navigation and page rendering
 - **Port: 8080 (Charon Management Interface)**
+- **Default Browser: Firefox** (provides best cross-browser compatibility baseline)

 **Integration Tests (Middleware Enforcement):**
 - Test Cerberus security module enforcement
@@ -61,7 +62,7 @@ For general integration testing without coverage:

 ```bash
 # Against Docker container (default)
-npx playwright test --project=chromium --project=firefox --project=webkit
+cd /projects/Charon npx playwright test --project=firefox --project=firefox --project=webkit

 # With explicit base URL
 PLAYWRIGHT_BASE_URL=http://localhost:8080 npx playwright test --project=chromium --project=firefox --project=webkit