@sallmarta/eye-hate-agent 1.0.2 → 1.0.4

package/docs/vibes/project-docs-template/operations/observability.md

@@ -1,53 +0,0 @@
-# Observability & Telemetry
-
-Last update: YYYY-MM-DD
-
-Status: [Proposed | Draft | Live | Deprecated | Archived]
-
----
-
-## 1. Description
-> [!NOTE] Briefly describe the purpose of this document and what it contains.
-
-## 2. Important
-> [!NOTE] Notes of important findings or critical constraints. Can be empty.
-
-## 3. Table of Contents
-> [!NOTE] TOC goes here.
-
-## 4. Scope
-> [!NOTE] The boundaries of what this document covers.
-
-## 5. Goals
-> [!NOTE] What we aim to achieve with this specific document.
-
-## 6. Non Goals
-> [!NOTE] What is explicitly excluded from the scope of this document.
-
-## 7. Logging Strategy & Levels
-> [!NOTE] Formatting (e.g., JSON) and severity rules (Info/Warn/Error).
-
-## 8. Metrics & Dashboards
-> [!NOTE] Key Performance Indicators (latency, error rates).
-
-## 9. Distributed Tracing
-> [!NOTE] Request IDs and flow mapping across microservices.
-
-## 10. Alerting Rules & Thresholds
-> [!NOTE] Conditions that trigger on-call pages. Flowcharts are preferred. Use mermaid.
-
-```mermaid
-graph TD
-    A[Alert Triggered] --> B{Severity Level}
-    B -- High --> C[Page On-Call]
-    B -- Low --> D[Log to Ticket]
-```
-
-## 11. Success Metrics
-> [!NOTE] How we measure if the goals of this document are achieved.
-
-## 12. Related Documents
-> [!NOTE] [Link to related document](path) - Short brief note about why it's related.
-
-## 13. Open Questions
-> [!NOTE] Any unresolved questions or assumptions. Can be empty.

package/docs/vibes/project-docs-template/operations/production-runbook.md

@@ -1,62 +0,0 @@
-# Production Runbook
-
-Last update: YYYY-MM-DD
-
-Status: [Proposed | Draft | Live | Deprecated | Archived]
-
----
-
-## 1. Description
-> [!NOTE] Describe what this runbook covers and which environment or service it applies to.
-
-## 2. Important
-> [!NOTE] Notes of important findings or critical constraints. Can be empty.
-
-## 3. Table of Contents
-> [!NOTE] TOC goes here.
-
-## 4. Scope
-> [!NOTE] The boundaries of what this document covers.
-
-## 5. Goals
-> [!NOTE] What we aim to achieve with this specific document.
-
-## 6. Non Goals
-> [!NOTE] What is explicitly excluded from the scope of this document.
-
-## 7. Environment Overview
-> [!NOTE] Production environment summary. Key dependencies or infrastructure notes.
-
-## 8. Prerequisites and Access
-- Required tools
-- Required permissions or credentials
-- Safety checks before making changes
-
-## 9. Release / Deployment Procedure
-1. Step 1
-2. Step 2
-3. Step 3
-
-## 10. Verification / Smoke Checks
-> [!NOTE] Checks to run to ensure deployment is healthy.
-
-## 11. Rollback / Recovery
-> [!NOTE] Steps to recover from a failed deployment. Flowcharts are preferred. Use mermaid.
-
-```mermaid
-graph TD
-    A[Failure Detected] --> B[Trigger Rollback]
-    B --> C[Verify Previous State]
-```
-
-## 12. Operational Notes
-> [!NOTE] Known gotchas.
-
-## 13. Success Metrics
-> [!NOTE] How we measure if the goals of this document are achieved.
-
-## 14. Related Documents
-> [!NOTE] [Link to related document](path) - Short brief note about why it's related.
-
-## 15. Open Questions
-> [!NOTE] Any unresolved questions or assumptions. Can be empty.

package/docs/vibes/project-docs-template/operations/security.md

@@ -1,49 +0,0 @@
-# Security
-
-Last update: YYYY-MM-DD
-
-Status: [Proposed | Draft | Live | Deprecated | Archived]
-
----
-
-## 1. Description
-> [!NOTE] Briefly describe the purpose of this document and what it contains.
-
-## 2. Important
-> [!NOTE] Notes of important findings or critical constraints. Can be empty.
-
-## 3. Table of Contents
-> [!NOTE] TOC goes here.
-
-## 4. Scope
-> [!NOTE] The boundaries of what this document covers.
-
-## 5. Goals
-> [!NOTE] What we aim to achieve with this specific document.
-
-## 6. Non Goals
-> [!NOTE] What is explicitly excluded from the scope of this document.
-
-## 7. Security Objectives
-> [!NOTE] Primary assets to protect.
-
-## 8. Identified Threats & Vectors
-> [!NOTE] Known vulnerabilities (e.g., injection, XSS, DDOS).
-
-## 9. Mitigation Strategies
-> [!NOTE] How the architecture neutralizes the threats.
-
-## 10. Access Control (RBAC)
-> [!NOTE] Roles, permissions, and session management.
-
-## 11. Data Encryption (At-Rest / In-Transit)
-> [!NOTE] Algorithms and key management.
-
-## 12. Success Metrics
-> [!NOTE] How we measure if the goals of this document are achieved.
-
-## 13. Related Documents
-> [!NOTE] [Link to related document](path) - Short brief note about why it's related.
-
-## 14. Open Questions
-> [!NOTE] Any unresolved questions or assumptions. Can be empty.

package/docs/vibes/project-docs-template/technical/api-contract.md

@@ -1,49 +0,0 @@
-# API Contract
-
-Last update: YYYY-MM-DD
-
-Status: [Proposed | Draft | Live | Deprecated | Archived]
-
----
-
-## 1. Description
-> [!NOTE] Briefly describe the purpose of this document and what it contains.
-
-## 2. Important
-> [!NOTE] Notes of important findings or critical constraints. Can be empty.
-
-## 3. Table of Contents
-> [!NOTE] TOC goes here.
-
-## 4. Scope
-> [!NOTE] The boundaries of what this document covers.
-
-## 5. Goals
-> [!NOTE] What we aim to achieve with this specific document.
-
-## 6. Non Goals
-> [!NOTE] What is explicitly excluded from the scope of this document.
-
-## 7. Base URL & Authentication
-> [!NOTE] Core connection details and token requirements.
-
-## 8. Standard Request/Response Format
-> [!NOTE] The expected shape of data (e.g., standard JSON wrapper).
-
-## 9. Endpoints (REST / GraphQL)
-> [!NOTE] Specific routes, methods, payloads, and responses.
-
-## 10. Webhooks & Events
-> [!NOTE] Outbound data events pushed to external systems.
-
-## 11. Rate Limiting & Constraints
-> [!NOTE] Throttling rules and payload size limits.
-
-## 12. Success Metrics
-> [!NOTE] How we measure if the goals of this document are achieved.
-
-## 13. Related Documents
-> [!NOTE] [Link to related document](path) - Short brief note about why it's related.
-
-## 14. Open Questions
-> [!NOTE] Any unresolved questions or assumptions. Can be empty.

package/docs/vibes/project-docs-template/technical/database.md

@@ -1,59 +0,0 @@
-# Database Schema
-
-Last update: YYYY-MM-DD
-
-Status: [Proposed | Draft | Live | Deprecated | Archived]
-
----
-
-## 1. Description
-> [!NOTE] Briefly describe the purpose of this document and what it contains.
-
-## 2. Important
-> [!NOTE] Notes of important findings or critical constraints. Can be empty.
-
-## 3. Table of Contents
-> [!NOTE] TOC goes here.
-
-## 4. Scope
-> [!NOTE] The boundaries of what this document covers.
-
-## 5. Goals
-> [!NOTE] What we aim to achieve with this specific document.
-
-## 6. Non Goals
-> [!NOTE] What is explicitly excluded from the scope of this document.
-
-## 7. Database Architecture
-> [!NOTE] Type of DB (SQL/NoSQL) and clustering details.
-
-## 8. Entity Relationship Diagram (ERD)
-> [!NOTE] Visual or text-based map of table relationships. ERDs are preferred. Use mermaid.
-
-```mermaid
-erDiagram
-    CUSTOMER ||--o{ ORDER : places
-    ORDER ||--|{ LINE-ITEM : contains
-    CUSTOMER }|..|{ DELIVERY-ADDRESS : uses
-```
-
-## 9. Schema Definitions (Tables/Collections)
-> [!NOTE] Specific columns, types, and constraints.
-
-## 10. Indexes & Performance
-> [!NOTE] Keys required for fast lookups.
-
-## 11. Migration Strategy
-> [!NOTE] How schema changes are versioned and deployed.
-
-## 12. Data Dictionary
-> [!NOTE] Single source of truth for business definitions. Define what key domain terms actually mean (e.g., "An *Active User* is someone who logged in within 30 days, excluding admins").
-
-## 13. Success Metrics
-> [!NOTE] How we measure if the goals of this document are achieved.
-
-## 14. Related Documents
-> [!NOTE] [Link to related document](path) - Short brief note about why it's related.
-
-## 15. Open Questions
-> [!NOTE] Any unresolved questions or assumptions. Can be empty.

package/docs/vibes/project-docs-template/technical/error-handling.md

@@ -1,54 +0,0 @@
-# Error Handling
-
-Last update: YYYY-MM-DD
-
-Status: [Proposed | Draft | Live | Deprecated | Archived]
-
----
-
-## 1. Description
-> [!NOTE] Briefly describe the purpose of this document and what it contains.
-
-## 2. Important
-> [!NOTE] Notes of important findings or critical constraints. Can be empty.
-
-## 3. Table of Contents
-> [!NOTE] TOC goes here.
-
-## 4. Scope
-> [!NOTE] The boundaries of what this document covers.
-
-## 5. Goals
-> [!NOTE] What we aim to achieve with this specific document.
-
-## 6. Non Goals
-> [!NOTE] What is explicitly excluded from the scope of this document.
-
-## 7. Standard Error Payload
-> [!NOTE] The exact JSON shape returned on failure.
-
-## 8. Global Error Codes
-> [!NOTE] A registry of specific business logic errors.
-
-## 9. Client-Side Handling Rules
-> [!NOTE] How the frontend should display or retry failures.
-
-## 10. Server-Side Fallbacks
-> [!NOTE] Circuit breakers and degraded modes. Diagram of fallback flow is preferred. Use mermaid.
-
-```mermaid
-graph TD
-    A[Request] --> B{Service Online?}
-    B -- Yes --> C[Process Request]
-    B -- No --> D[Trigger Circuit Breaker]
-    D --> E[Return Fallback Payload]
-```
-
-## 11. Success Metrics
-> [!NOTE] How we measure if the goals of this document are achieved.
-
-## 12. Related Documents
-> [!NOTE] [Link to related document](path) - Short brief note about why it's related.
-
-## 13. Open Questions
-> [!NOTE] Any unresolved questions or assumptions. Can be empty.

package/docs/vibes/project-docs-template/technical/internationalization.md

@@ -1,46 +0,0 @@
-# Internationalization & Localization
-
-Last update: YYYY-MM-DD
-
-Status: [Proposed | Draft | Live | Deprecated | Archived]
-
----
-
-## 1. Description
-> [!NOTE] Briefly describe the purpose of this document and what it contains.
-
-## 2. Important
-> [!NOTE] Notes of important findings or critical constraints. Can be empty.
-
-## 3. Table of Contents
-> [!NOTE] TOC goes here.
-
-## 4. Scope
-> [!NOTE] The boundaries of what this document covers.
-
-## 5. Goals
-> [!NOTE] What we aim to achieve with this specific document.
-
-## 6. Non Goals
-> [!NOTE] What is explicitly excluded from the scope of this document.
-
-## 7. Supported Languages / Locales
-> [!NOTE] The explicit list of target regions.
-
-## 8. Translation Workflow (TMS)
-> [!NOTE] How strings are extracted, translated, and merged.
-
-## 9. Fallback Locales
-> [!NOTE] The default language when a string is missing.
-
-## 10. Date & Currency Formats
-> [!NOTE] Regional formatting rules.
-
-## 11. Success Metrics
-> [!NOTE] How we measure if the goals of this document are achieved.
-
-## 12. Related Documents
-> [!NOTE] [Link to related document](path) - Short brief note about why it's related.
-
-## 13. Open Questions
-> [!NOTE] Any unresolved questions or assumptions. Can be empty.

package/docs/vibes/project-docs-template/technical/testing.md

@@ -1,57 +0,0 @@
-# Testing & Verification
-
-Last update: YYYY-MM-DD
-
-Status: [Proposed | Draft | Live | Deprecated | Archived]
-
----
-
-## 1. Description
-> [!NOTE] Briefly describe the purpose of this document and what it contains.
-
-## 2. Important
-> [!NOTE] Notes of important findings or critical constraints. Can be empty.
-
-## 3. Table of Contents
-> [!NOTE] TOC goes here.
-
-## 4. Scope
-> [!NOTE] The boundaries of what this document covers.
-
-## 5. Goals
-> [!NOTE] What we aim to achieve with this specific document.
-
-## 6. Non Goals
-> [!NOTE] What is explicitly excluded from the scope of this document.
-
-## 7. Verification Policy & Objectives
-> [!NOTE] Define the overarching philosophy for how this repository chooses, runs, and reports testing. What are we trying to prove with our test suite?
-
-## 8. Verification Matrix & Coverage
-> [!NOTE] The required types of testing (Blackbox, Unit, Security) mapping against expected coverage metrics (e.g., 85% branch coverage).
-
-| Change type | Preferred validation | Fallback |
-| --- | --- | --- |
-| Code change | TBD | TBD |
-| Documentation change | TBD | TBD |
-
-## 9. Test Layers & Environments
-> [!NOTE] Detail the exact split of Unit, Component, Integration, and E2E tests. Include the required infrastructure, mocks, and seed data needed to run them.
-
-## 10. Commands & CI Gates
-> [!NOTE] The exact terminal commands for linting and testing. Outline the required pre-merge CI checks (blocking vs advisory).
-
-## 11. Naming & File Conventions
-> [!NOTE] Where tests live, how test files are named (e.g., `*.spec.ts`), and how fixtures are stored.
-
-## 12. Manual Checks & Fallbacks
-> [!NOTE] Necessary manual testing steps and fallback procedures for human verification when automation is impossible.
-
-## 13. Success Metrics
-> [!NOTE] How we measure if the goals of this document are achieved.
-
-## 14. Related Documents
-> [!NOTE] [Link to related document](path) - Short brief note about why it's related.
-
-## 15. Open Questions
-> [!NOTE] Any unresolved questions or assumptions. Can be empty.

package/docs/vibes/project-docs-template/technical/ui-ux.md

@@ -1,68 +0,0 @@
-# UI/UX
-
-Last update: YYYY-MM-DD
-
-Status: [Proposed | Draft | Live | Deprecated | Archived]
-
----
-
-## 1. Description
-> [!NOTE] Briefly describe the purpose of this document and what it contains.
-
-## 2. Important
-> [!NOTE] Notes of important findings or critical constraints. Can be empty.
-
-## 3. Table of Contents
-> [!NOTE] TOC goes here.
-
-## 4. Scope
-> [!NOTE] The boundaries of what this document covers.
-
-## 5. Goals
-> [!NOTE] What we aim to achieve with this specific document.
-
-## 6. Non Goals
-> [!NOTE] What is explicitly excluded from the scope of this document.
-
-## 7. Design Philosophy
-> [!NOTE] The core principles guiding the user experience.
-
-## 8. Design System & Theme
-> [!NOTE] Colors, typography, and visual guidelines.
-
-## 9. Wireframing & Prototyping
-> [!NOTE] Links to external tools (Figma, Adobe) or raw UI specs generated by humans/AI in the repo.
-
-## 10. Screen Layouts
-> [!NOTE] Core page structures and navigation flows. Wireframes are preferred. Use mermaid.
-
-```mermaid
-graph TD
-    A[Home Page] --> B[Dashboard]
-    A --> C[Profile Settings]
-    B --> D[Details View]
-```
-
-## 11. Component Library
-> [!NOTE] Reusable UI elements (buttons, modals).
-
-## 12. Responsive Breakpoints
-> [!NOTE] Behavior across mobile, tablet, and desktop.
-
-## 13. Accessibility (a11y) Requirements
-> [!NOTE] Contrast ratios, ARIA labels.
-
-## 14. Implementation Backlog
-> [!NOTE] List of UI tasks (e.g., `Task-ID: Description`).
-
-## 15. Design Handoff Approaches
-> [!NOTE] How designs are explicitly transferred to developers.
-
-## 16. Success Metrics
-> [!NOTE] How we measure if the goals of this document are achieved.
-
-## 17. Related Documents
-> [!NOTE] [Link to related document](path) - Short brief note about why it's related.
-
-## 18. Open Questions
-> [!NOTE] Any unresolved questions or assumptions. Can be empty.

package/docs/vibes/project-docs-template/technical-guidelines/index.md

@@ -1,52 +0,0 @@
-# Guidelines Index
-
-Last update: YYYY-MM-DD
-
-Status: [Proposed | Draft | Live | Deprecated | Archived]
-
----
-
-## 1. Summary
-> [!NOTE] Use this index to list the active technical guideline documents for the repository. Core project docs explain the repository generally. Guidelines explain the durable technical rules that recurring implementation and review work should follow. This index is the authoritative registry for active guideline types; starter template files are recommended references, not the activation mechanism.
-
-## 2. When To Add A Guideline
-- Add a guideline when a technical domain has cross-cutting rules that would otherwise be repeated across tasks.
-- Do not create a guideline as a placeholder.
-- Keep one primary domain per guideline file.
-- If a rule is broad project truth, keep it in the core project docs and reference that doc here instead.
-- Add a new row in the `## 3. Active Guidelines` table below when activating a known guideline type, even if no starter template file exists for it yet.
-
-## 3. Active Guidelines
-| Guideline | Domain | Purpose | Owner | Review trigger |
-| --- | --- | --- | --- | --- |
-| `technical-guidelines/api.md` | API | Request or response contracts, versioning rules, and integration boundaries | TBD | API contract or integration changes |
-| `technical-guidelines/database.md` | Database | Schema, migration, naming, and persistence rules | TBD | Schema or storage changes |
-| `technical-guidelines/logging.md` | Logging | Event naming, log levels, redaction, and correlation rules | TBD | Logging policy or observability changes |
-| `technical-guidelines/error-handling.md` | Error handling | Error taxonomy, propagation, user-safe messages, and fallback rules | TBD | Error model or operational changes |
-| `technical-guidelines/json.md` | JSON | Serialization, naming, nullability, and payload-shape rules | TBD | Payload or contract changes |
-| `technical-guidelines/code-style.md` | Code style | Repo-specific style rules beyond formatter and linter defaults | TBD | Tooling or style-policy changes |
-| `technical-guidelines/design-patterns.md` | Design patterns | Preferred design patterns, boundary patterns, and forbidden coupling | TBD | Architecture or module-boundary changes |
-| `technical-guidelines/internationalization.md` | i18n/l10n | Rules for i18n keys, fallbacks, and adding new languages | TBD | i18n tooling or language changes |
-| `technical-guidelines/testing.md` | Testing | Rules for writing tests, naming conventions, mocking, and coverage | TBD | Testing framework or coverage changes |
-| `technical-guidelines/ui-ux.md` | UI/UX | Rules for UI components, accessibility standards, and design system usage | TBD | Design system or component library changes |
-| `technical-guidelines/your-new-guideline.md` | State the domain of the next guideline here | State the purpose of the next guideline here | TBD | State the review trigger for the next guideline here |
-
-> [!NOTE] Remove rows for inactive domains and add a new row in the `## 3. Active Guidelines` table above for any other active guideline files.
-
-## 4. Ownership And Review
-- Keep this index aligned with the files that actually exist under `technical-guidelines/`.
-- A row in this index activates a known guideline type for bootstrap, refresh, and parity behavior.
-- If no starter template file exists for a listed guideline type, use the stable guideline headings from the contract.
-- Update the relevant row whenever a guideline changes owner, scope, or review trigger.
-- Cross-reference owning project docs such as `architecture.md` or `testing.md` when a guideline depends on them.
-
-## 5. Stable Headings
-> [!NOTE] New guideline files must include the standard numbered headings below to keep all rulebooks consistent. Feel free to add extra domain-specific headings if needed.
-
-1. **`## 1. Summary`**: A brief overview of what rules this guideline documents.
-2. **`## 2. Scope`**: The explicit boundaries of what these rules cover (and don't cover).
-3. **`## 3. Rules`**: The hard rules that must be followed.
-4. **`## 4. Preferred Patterns`**: Examples or guidelines of the *best* way to do something.
-5. **`## 5. Anti-Patterns`**: Examples of what *not* to do.
-6. **`## 6. Related Docs`**: Links to `technical/` docs or other guidelines.
-7. **`## 7. Open Questions`**: Any unresolved rules or edge cases.

package/docs/vibes/reusable-prompts/00-project-docs-bootstrap.md

@@ -1,59 +0,0 @@
-# Project Docs Bootstrap Reusable Prompt (v2.0.0)
-
-Read `docs/eyehateagent-contract.md` first.
-
-Generate the **initial project documentation set** for a repository. 
-You must dynamically adjust your behavior based on the current state of the repository.
-
-## State Detection (Universal Document Handler)
-Before writing any documents, analyze the workspace to determine its state:
-1. **Zero Docs (Fresh Repo):** No existing documentation and no code. You must ask the user questions to build the specifications from scratch.
-2. **Unclear Docs (Running Repo):** Code exists but docs are missing or outdated. Analyze the existing codebase (package files, database schemas, api routes) to reverse-engineer `foundation/architecture.md` and `technical/database.md`. Ask the user to fill in the missing product goals.
-3. **Mature Docs:** Existing legacy documentation exists but isn't in the EHA format. Map the existing docs into the new 4-layer taxonomy `docs/project-docs/` format without losing historical context.
-
-## Required Behavior
-1. Follow the 4-layer file structure defined in `docs/eyehateagent-contract.md` (`foundation/`, `operations/`, `technical/`, `technical-guidelines/`).
-2. Create project-specific truth in `docs/project-docs/`, not in the reusable prompt output itself.
-3. Do not invent details. Mark uncertain facts as `TBD` or `Assumption`.
-4. If reverse-engineering from code, explicitly state "Inferred from codebase" in the generated document until the user confirms it.
-
-## Output Contract (The Massive Document Structure)
-Create these files under `docs/project-docs/`. If you lack the context to fill them out, generate the markdown headings and mark the content as TBD.
-
-**Root:**
-- `index.md`
-- `getting-started.md`
-
-**Foundation:**
-- `foundation/prd.md`
-- `foundation/architecture.md`
-- `foundation/workflow.md`
-- `foundation/status.md`
-- `foundation/phases.md`
-- `foundation/changelog.md`
-- `foundation/feature-inventory.md`
-
-**Operations:**
-- `operations/ci-cd.md`
-- `operations/production-runbook.md`
-- `operations/governance.md`
-- `operations/compliance.md`
-- `operations/observability.md`
-- `operations/security.md`
-
-**Technical:**
-- `technical/testing.md`
-- `technical/api-contract.md`
-- `technical/database.md`
-- `technical/ui-ux.md`
-- `technical/error-handling.md`
-- `technical/internationalization.md`
-
-## Final Pass
-Before finishing, check that:
-1. No files are generated in the root of `project-docs/` except `index.md` and `getting-started.md`. Everything else must be in its respective subfolder.
-2. `foundation/architecture.md` and `technical/testing.md` do not conflict.
-3. The generated documents strictly follow the Flexible Baselines principle (you may omit heavily specialized docs if the user confirms they aren't needed).
-
-## Inputs
-Use the project brief, codebase, and constraints provided below to begin generation.