This commit is contained in:
@@ -1,29 +0,0 @@
|
|||||||
# Investigation - External Dogs UI Issues
|
|
||||||
|
|
||||||
## Bug Summary
|
|
||||||
The "External Dogs" interface does not match the layout and style of the main "Dogs" page. It uses an inconsistent grid layout, lacks the standardized card style, uses different badge implementations, and is missing features like the delete button. Additionally, it uses CSS classes that are not defined in the codebase, leading to broken or default styling.
|
|
||||||
|
|
||||||
## Root Cause Analysis
|
|
||||||
- **Inconsistent Layout**: `DogList.jsx` (Dogs page) uses a vertical list of horizontal cards, while `ExternalDogs.jsx` uses a grid of square-ish cards.
|
|
||||||
- **Undefined CSS Classes**: `ExternalDogs.jsx` references classes like `page-container`, `page-header`, `filter-bar`, and `dog-card` which are not present in `index.css` or `App.css`.
|
|
||||||
- **Missing Components**: `ExternalDogs.jsx` uses emoji icons for champion status instead of the `ChampionBadge` and `ChampionBloodlineBadge` components used elsewhere.
|
|
||||||
- **Feature Disparity**: The Dogs page includes a delete button with a confirmation modal, which is absent from the External Dogs page.
|
|
||||||
- **Helper Usage**: `ExternalDogs.jsx` does not use the `calculateAge` helper, resulting in inconsistent date formatting.
|
|
||||||
|
|
||||||
## Affected Components
|
|
||||||
- `client/src/pages/ExternalDogs.jsx`
|
|
||||||
|
|
||||||
## Implementation Notes
|
|
||||||
Refactored `ExternalDogs.jsx` to match `DogList.jsx` in layout, style, and functionality. Key changes:
|
|
||||||
- Switched to `axios` for API calls.
|
|
||||||
- Adopted the vertical list layout instead of the grid.
|
|
||||||
- Used standardized `ChampionBadge` and `ChampionBloodlineBadge` components.
|
|
||||||
- Added a search/filter bar consistent with the main Dogs page.
|
|
||||||
- Implemented delete functionality with a confirmation modal.
|
|
||||||
- Standardized age calculation using the `calculateAge` helper logic.
|
|
||||||
- Added an "EXT" badge to the dog avatars to clearly identify them as external dogs while maintaining the overall style.
|
|
||||||
|
|
||||||
## Test Results
|
|
||||||
- Verified that all components are correctly imported.
|
|
||||||
- Verified that API endpoints match the backend routes.
|
|
||||||
- Code review shows consistent use of CSS variables and classes (e.g., `container`, `card`, `btn`).
|
|
||||||
@@ -1,31 +0,0 @@
|
|||||||
# Investigation: Bug in Pairing Simulator
|
|
||||||
|
|
||||||
## Bug Summary
|
|
||||||
In the Pairing Simulator page, clicking the "Simulate Pairing" button results in the following error:
|
|
||||||
`Unexpected token '<', "<!--DOCTYPE "... is not valid JSON`
|
|
||||||
|
|
||||||
## Root Cause Analysis
|
|
||||||
The frontend `PairingSimulator.jsx` makes a POST request to `/api/pedigree/coi` when simulating a pairing. However, the backend `server/routes/pedigree.js` does not define a `/coi` route. Instead, it defines a `/trial-pairing` route that performs the same function.
|
|
||||||
|
|
||||||
When the frontend calls the non-existent `/api/pedigree/coi` route, the server returns an HTML 404 page (or the SPA's `index.html` if in production). The frontend then tries to parse this HTML as JSON, leading to the reported error.
|
|
||||||
|
|
||||||
Additionally, `PedigreeView.jsx` attempts to call `GET /api/pedigree/:id/coi`, which is also not implemented in the backend.
|
|
||||||
|
|
||||||
## Affected Components
|
|
||||||
- `client/src/pages/PairingSimulator.jsx`: Calls `/api/pedigree/coi` (POST).
|
|
||||||
- `client/src/pages/PedigreeView.jsx`: Calls `/api/pedigree/:id/coi` (GET).
|
|
||||||
- `server/routes/pedigree.js`: Missing route definitions for `/coi` and `/:id/coi`.
|
|
||||||
|
|
||||||
## Proposed Solution
|
|
||||||
1. Update `server/routes/pedigree.js` to:
|
|
||||||
- Alias `POST /api/pedigree/coi` to the existing `trial-pairing` logic.
|
|
||||||
- Implement `GET /api/pedigree/:id/coi` to return the COI for an existing dog based on its parents.
|
|
||||||
2. Ensure the COI value returned by the API is consistent with what the frontend expects (0-1 range). Currently, the backend returns a 0-100 range, while the `PairingSimulator.jsx` expects 0-1 and multiplies by 100 in the UI.
|
|
||||||
|
|
||||||
## Implementation Plan
|
|
||||||
1. **Backend Changes**:
|
|
||||||
- Modify `server/routes/pedigree.js` to add `router.post('/coi', ...)` using the same logic as `trial-pairing`.
|
|
||||||
- Add `router.get('/:id/coi', ...)` to `server/routes/pedigree.js`.
|
|
||||||
- Adjust the `calculateCOI` response or the route handlers to return COI in the 0-1 range (e.g. `0.05` for 5%) to match `PairingSimulator.jsx`'s expectation.
|
|
||||||
2. **Frontend Cleanup**:
|
|
||||||
- Check if `PedigreeView.jsx` and `pedigreeHelpers.js` need adjustments once the backend returns the 0-1 range. `formatCOI` in `pedigreeHelpers.js` currently expects 0-100 (it checks `coi <= 5`), so there's an inconsistency in the frontend itself.
|
|
||||||
@@ -1,87 +0,0 @@
|
|||||||
# Full SDD workflow
|
|
||||||
|
|
||||||
## Configuration
|
|
||||||
- **Artifacts Path**: {@artifacts_path} → `.zenflow/tasks/{task_id}`
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Agent Instructions
|
|
||||||
|
|
||||||
If you are blocked and need user clarification, mark the current step with `[!]` in plan.md before stopping.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Workflow Steps
|
|
||||||
|
|
||||||
### [x] Step: Requirements
|
|
||||||
<!-- chat-id: c41b4352-a09d-4280-9aa2-cf29378edb68 -->
|
|
||||||
|
|
||||||
Create a Product Requirements Document (PRD) based on the feature description.
|
|
||||||
|
|
||||||
1. Review existing codebase to understand current architecture and patterns
|
|
||||||
2. Analyze the feature definition and identify unclear aspects
|
|
||||||
3. Ask the user for clarifications on aspects that significantly impact scope or user experience
|
|
||||||
4. Make reasonable decisions for minor details based on context and conventions
|
|
||||||
5. If user can't clarify, make a decision, state the assumption, and continue
|
|
||||||
|
|
||||||
Save the PRD to `{@artifacts_path}/requirements.md`.
|
|
||||||
|
|
||||||
### [x] Step: Technical Specification
|
|
||||||
<!-- chat-id: c8a2d821-c232-4b10-a4b9-471df9e53543 -->
|
|
||||||
|
|
||||||
Create a technical specification based on the PRD in `{@artifacts_path}/requirements.md`.
|
|
||||||
|
|
||||||
1. Review existing codebase architecture and identify reusable components
|
|
||||||
2. Define the implementation approach
|
|
||||||
|
|
||||||
Save to `{@artifacts_path}/spec.md` with:
|
|
||||||
- Technical context (language, dependencies)
|
|
||||||
- Implementation approach referencing existing code patterns
|
|
||||||
- Source code structure changes
|
|
||||||
- Data model / API / interface changes
|
|
||||||
- Delivery phases (incremental, testable milestones)
|
|
||||||
- Verification approach using project lint/test commands
|
|
||||||
|
|
||||||
### [x] Step: Planning
|
|
||||||
<!-- chat-id: 5128cbb3-0529-47f2-a7ac-9a978ea72267 -->
|
|
||||||
|
|
||||||
Create a detailed implementation plan based on `{@artifacts_path}/spec.md`.
|
|
||||||
|
|
||||||
1. Break down the work into concrete tasks
|
|
||||||
2. Each task should reference relevant contracts and include verification steps
|
|
||||||
3. Replace the Implementation step below with the planned tasks
|
|
||||||
|
|
||||||
Rule of thumb for step size: each step should represent a coherent unit of work (e.g., implement a component, add an API endpoint). Avoid steps that are too granular (single function) or too broad (entire feature).
|
|
||||||
|
|
||||||
Important: unit tests must be part of each implementation task, not separate tasks. Each task should implement the code and its tests together, if relevant.
|
|
||||||
|
|
||||||
If the feature is trivial and doesn't warrant full specification, update this workflow to remove unnecessary steps and explain the reasoning to the user.
|
|
||||||
|
|
||||||
Save to `{@artifacts_path}/plan.md`.
|
|
||||||
|
|
||||||
### [x] Phase 1: Create DEVELOPMENT.md
|
|
||||||
<!-- chat-id: 0da2c64e-4b20-423d-9049-46fc0467eaec -->
|
|
||||||
1. Research tech stack, monorepo structure, and database schemas in `server/db/`.
|
|
||||||
2. Document the "Parents Table" approach and database initialization/migration.
|
|
||||||
3. Add setup and development commands.
|
|
||||||
4. Verify correctness against `server/db/init.js` and `package.json`.
|
|
||||||
|
|
||||||
### [x] Phase 2: Create API.md
|
|
||||||
<!-- chat-id: bde368a7-164c-419e-b4b9-582e6ced4a45 -->
|
|
||||||
1. Research all routes in `server/routes/` for endpoints, methods, parameters, and responses.
|
|
||||||
2. Document endpoint groups: Dogs, Litters, Health, Genetics, Breeding, and Settings.
|
|
||||||
3. Provide JSON schema examples for key data models (Dog, Litter, etc.).
|
|
||||||
4. Verify endpoints against route handlers in `server/routes/`.
|
|
||||||
|
|
||||||
### [x] Phase 3: Create FRONTEND_GUIDE.md
|
|
||||||
<!-- chat-id: f0c53f46-3014-4030-9433-3df4d730fde7 -->
|
|
||||||
1. Research React patterns, hooks (`useSettings`), and `PedigreeTree` logic.
|
|
||||||
2. Document routing, state management, and key reusable components (`DogForm`, `PedigreeTree`, etc.).
|
|
||||||
3. Explain styling conventions and theme implementation using CSS variables.
|
|
||||||
4. Verify patterns against `client/src/App.jsx`, `client/src/hooks/`, and `client/src/components/`.
|
|
||||||
|
|
||||||
### [x] Phase 4: Final Review and Verification
|
|
||||||
<!-- chat-id: b87b4e6a-5d6a-4ad2-91dc-70916b830845 -->
|
|
||||||
1. Cross-reference all new documentation files with the current codebase (v0.6.1).
|
|
||||||
2. Ensure consistent formatting and clarity across all three files.
|
|
||||||
3. Verify that an agent can understand how to implement a new feature using only these documents.
|
|
||||||
@@ -1,44 +0,0 @@
|
|||||||
# Product Requirements Document (PRD) - INIT (Codebase Documentation)
|
|
||||||
|
|
||||||
## 1. Goal
|
|
||||||
The primary goal of this task is to perform a comprehensive scan of the Breedr codebase and create essential developer-focused documentation (`.md` files). This documentation will streamline the onboarding of new agents or developers and simplify the process of implementing new features and fixing bugs.
|
|
||||||
|
|
||||||
## 2. Target Audience
|
|
||||||
- AI Agents performing code modifications.
|
|
||||||
- Human developers contributing to the project.
|
|
||||||
|
|
||||||
## 3. Scope of Documentation
|
|
||||||
|
|
||||||
### 3.1 DEVELOPMENT.md (Architecture & General Guide)
|
|
||||||
This document will serve as the entry point for understanding the Breedr system.
|
|
||||||
- **Tech Stack Overview**: React, Express, SQLite (better-sqlite3).
|
|
||||||
- **Architecture**: Monorepo structure (`client/`, `server/`), data flow, and core principles.
|
|
||||||
- **Database System**: Detailed explanation of the "Parents Table" approach vs. traditional `sire_id`/`dam_id` columns, migration strategies, and schema initialization.
|
|
||||||
- **Project Structure**: High-level explanation of key directories and files.
|
|
||||||
- **Development Workflow**: How to run the app locally, common commands, and testing procedures (if any).
|
|
||||||
- **Coding Standards**: Patterns for backend routes and frontend components.
|
|
||||||
|
|
||||||
### 3.2 API.md (REST API Documentation)
|
|
||||||
A comprehensive list of all backend API endpoints.
|
|
||||||
- **Endpoint Definitions**: URL, method, and purpose.
|
|
||||||
- **Request Parameters**: Headers, query params, and body schemas.
|
|
||||||
- **Response Format**: Expected JSON structure and status codes.
|
|
||||||
- **Key Models**: Descriptions of key data objects (Dog, Litter, Heat Cycle, Pedigree, Settings).
|
|
||||||
|
|
||||||
### 3.3 FRONTEND_GUIDE.md (UI/UX & React Patterns)
|
|
||||||
A guide focusing on the client-side implementation.
|
|
||||||
- **Context & Hooks**: Documentation of `useSettings`, `SettingsProvider`, and any other shared state mechanisms.
|
|
||||||
- **Component Patterns**: Key reusable components (`DogForm`, `PedigreeTree`, etc.).
|
|
||||||
- **Styling**: Use of CSS custom properties (theming) and global styles.
|
|
||||||
- **Pedigree Visualization**: How `react-d3-tree` is integrated and used for genealogy mapping.
|
|
||||||
- **Routing**: Client-side navigation structure using `react-router-dom`.
|
|
||||||
|
|
||||||
## 4. Non-Functional Requirements
|
|
||||||
- **Consistency**: Documentation must match the current state (v0.6.1) of the codebase.
|
|
||||||
- **Clarity**: Use clear, concise language and code examples where appropriate.
|
|
||||||
- **Maintainability**: Organize documents so they are easy to update when new features are added.
|
|
||||||
|
|
||||||
## 5. Success Criteria
|
|
||||||
- The three proposed documentation files (`DEVELOPMENT.md`, `API.md`, `FRONTEND_GUIDE.md`) are created in the project root.
|
|
||||||
- The documentation accurately reflects the current codebase architecture, API, and frontend patterns.
|
|
||||||
- An agent can use these documents to understand how to implement a new feature (e.g., adding a new field to the Dog model) without scanning the entire codebase.
|
|
||||||
@@ -1,89 +0,0 @@
|
|||||||
# Technical Specification - Codebase Documentation (INIT)
|
|
||||||
|
|
||||||
This specification outlines the plan for creating comprehensive developer documentation for the Breedr codebase.
|
|
||||||
|
|
||||||
## Technical Context
|
|
||||||
- **Backend**: Node.js, Express, `better-sqlite3`.
|
|
||||||
- **Frontend**: React (Vite), `react-router-dom`, `axios`, `react-d3-tree`.
|
|
||||||
- **Database**: SQLite (managed via `server/db/init.js` and `server/db/migrations.js`).
|
|
||||||
- **Structure**: Monorepo-style with `client/` and `server/` directories.
|
|
||||||
|
|
||||||
## Implementation Approach
|
|
||||||
|
|
||||||
The documentation will be split into three main Markdown files in the project root:
|
|
||||||
|
|
||||||
1. **DEVELOPMENT.md**: Focuses on architecture, database design, and workflow.
|
|
||||||
2. **API.md**: Detailed documentation of all REST API endpoints.
|
|
||||||
3. **FRONTEND_GUIDE.md**: Focuses on React patterns, components, and styling.
|
|
||||||
|
|
||||||
### Research Methodology
|
|
||||||
- **Database**: Analyze `server/db/init.js` for table schemas and `parents` table logic.
|
|
||||||
- **API**: Scan `server/routes/*.js` for endpoints, middleware, and request/response structures.
|
|
||||||
- **Frontend**: Analyze `client/src/App.jsx` for routing, `client/src/hooks/` for state management, and `client/src/components/` for reusable patterns.
|
|
||||||
|
|
||||||
## Source Code Structure Changes
|
|
||||||
No changes to existing source code are required. Three new files will be created in the root directory:
|
|
||||||
- `/DEVELOPMENT.md`
|
|
||||||
- `/API.md`
|
|
||||||
- `/FRONTEND_GUIDE.md`
|
|
||||||
|
|
||||||
## Documentation Structure
|
|
||||||
|
|
||||||
### 1. DEVELOPMENT.md
|
|
||||||
- **Overview**: System purpose and high-level architecture.
|
|
||||||
- **Project Layout**: Description of key directories (`client`, `server`, `data`, `static`, `uploads`).
|
|
||||||
- **Database Design**:
|
|
||||||
- Explain the "Parents Table" approach (decoupling genealogy from the `dogs` table).
|
|
||||||
- Schema overview (Dogs, Litters, Health, Genetics, Settings).
|
|
||||||
- Initialization and migration process.
|
|
||||||
- **Getting Started**:
|
|
||||||
- `npm install` (root and client).
|
|
||||||
- `npm run dev` (concurrent execution).
|
|
||||||
- Database initialization (`npm run db:init`).
|
|
||||||
- **Coding Standards**: Backend route structure, async/await usage, error handling.
|
|
||||||
|
|
||||||
### 2. API.md
|
|
||||||
- **Base URL**: `/api`
|
|
||||||
- **Authentication**: (Note if any exists, currently seems open).
|
|
||||||
- **Endpoint Groups**:
|
|
||||||
- `Dogs`: CRUD operations, photo management, parent/offspring retrieval.
|
|
||||||
- `Litters`: Management of whelping records.
|
|
||||||
- `Health`: OFA records and test results.
|
|
||||||
- `Genetics`: DNA panel markers and results.
|
|
||||||
- `Breeding`: Breeding records and pairing simulations.
|
|
||||||
- `Settings`: Kennel profile management.
|
|
||||||
- **Data Models**: JSON schema examples for Dog, Litter, HealthRecord, etc.
|
|
||||||
|
|
||||||
### 3. FRONTEND_GUIDE.md
|
|
||||||
- **Tech Stack**: Vite, React, CSS Modules/Global CSS.
|
|
||||||
- **Routing**: `react-router-dom` configuration in `App.jsx`.
|
|
||||||
- **State Management**: `SettingsProvider` and `useSettings` hook.
|
|
||||||
- **Pedigree Engine**: Implementation of `react-d3-tree` and `pedigreeHelpers.js`.
|
|
||||||
- **Key Components**:
|
|
||||||
- `DogForm`: Complex form with parent selection.
|
|
||||||
- `PedigreeTree`: SVG-based genealogy visualization.
|
|
||||||
- `ClearanceSummaryCard`: Health status overview.
|
|
||||||
- **Styling**: Theming with CSS variables (found in `index.css` and `App.css`).
|
|
||||||
|
|
||||||
## Delivery Phases
|
|
||||||
|
|
||||||
### Phase 1: Core Architecture & Database (DEVELOPMENT.md)
|
|
||||||
- Document the tech stack and monorepo structure.
|
|
||||||
- Detail the SQLite schema and genealogy logic.
|
|
||||||
- Add setup and development commands.
|
|
||||||
|
|
||||||
### Phase 2: API Documentation (API.md)
|
|
||||||
- Document all routes in `server/routes/`.
|
|
||||||
- Provide request/response examples.
|
|
||||||
- Document the `parents` table integration in API responses.
|
|
||||||
|
|
||||||
### Phase 3: Frontend Guide (FRONTEND_GUIDE.md)
|
|
||||||
- Document React component patterns and hooks.
|
|
||||||
- Explain the pedigree visualization logic.
|
|
||||||
- Document routing and styling conventions.
|
|
||||||
|
|
||||||
## Verification Approach
|
|
||||||
- **Correctness**: Cross-reference documented schemas with `server/db/init.js`.
|
|
||||||
- **Accuracy**: Test documented API endpoints against the running server if possible, or verify via route handlers.
|
|
||||||
- **Completeness**: Ensure all components in `client/src/components` and routes in `server/routes` are mentioned or categorized.
|
|
||||||
- **Formatting**: Use `markdownlint` (if available) or manual review to ensure readability.
|
|
||||||
@@ -1,44 +0,0 @@
|
|||||||
# Fix bug
|
|
||||||
|
|
||||||
## Configuration
|
|
||||||
- **Artifacts Path**: {@artifacts_path} → `.zenflow/tasks/{task_id}`
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Agent Instructions
|
|
||||||
|
|
||||||
If you are blocked and need user clarification, mark the current step with `[!]` in plan.md before stopping.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Workflow Steps
|
|
||||||
|
|
||||||
### [x] Step: Investigation and Planning
|
|
||||||
<!-- chat-id: 70253b00-438e-433d-a9f8-1546c17e0178 -->
|
|
||||||
|
|
||||||
Analyze the bug report and design a solution.
|
|
||||||
|
|
||||||
1. Review the bug description, error messages, and logs
|
|
||||||
2. Clarify reproduction steps with the user if unclear
|
|
||||||
3. Check existing tests for clues about expected behavior
|
|
||||||
4. Locate relevant code sections and identify root cause
|
|
||||||
5. Propose a fix based on the investigation
|
|
||||||
6. Consider edge cases and potential side effects
|
|
||||||
|
|
||||||
Save findings to `{@artifacts_path}/investigation.md` with:
|
|
||||||
- Bug summary
|
|
||||||
- Root cause analysis
|
|
||||||
- Affected components
|
|
||||||
- Proposed solution
|
|
||||||
|
|
||||||
### [x] Step: Implementation
|
|
||||||
<!-- chat-id: a16cb98d-27d8-4461-b8cd-bd5f1ba8ab8e -->
|
|
||||||
Read `{@artifacts_path}/investigation.md`
|
|
||||||
Implement the bug fix.
|
|
||||||
|
|
||||||
1. Add/adjust regression test(s) that fail before the fix and pass after
|
|
||||||
2. Implement the fix
|
|
||||||
3. Run relevant tests
|
|
||||||
4. Update `{@artifacts_path}/investigation.md` with implementation notes and test results
|
|
||||||
|
|
||||||
If blocked or uncertain, ask the user for direction.
|
|
||||||
@@ -1,32 +0,0 @@
|
|||||||
# Bug Investigation & Implementation Report - Task 7382
|
|
||||||
|
|
||||||
## Bug Summary
|
|
||||||
The Pairing Simulator was failing with the error: `Unexpected token '<', "<!DOCTYPE "... is not valid JSON`. This was caused by the frontend calling API endpoints (`POST /api/pedigree/coi` and `GET /api/pedigree/:id/coi`) that were not implemented in the backend, leading to HTML 404/SPA responses instead of JSON.
|
|
||||||
|
|
||||||
## Root Cause Analysis
|
|
||||||
1. **Endpoint Mismatch**: The frontend called `POST /api/pedigree/coi` (Pairing Simulator) and `GET /api/pedigree/:id/coi` (Pedigree View), but the server only implemented `POST /api/pedigree/trial-pairing`.
|
|
||||||
2. **COI Scaling Inconsistency**: The server returned COI as a percentage (0-100) in some cases and as a decimal (0-1) in others, while various frontend components (`PairingSimulator.jsx`, `PedigreeView.jsx`, `PedigreeTree.jsx`, `pedigreeHelpers.js`) had differing expectations.
|
|
||||||
3. **Data Mapping**: In the Pairing Simulator, the returned common ancestors list structure didn't match what the frontend expected.
|
|
||||||
|
|
||||||
## Affected Components
|
|
||||||
- `client/src/pages/PairingSimulator.jsx`
|
|
||||||
- `client/src/pages/PedigreeView.jsx`
|
|
||||||
- `client/src/components/PedigreeTree.jsx`
|
|
||||||
- `client/src/utils/pedigreeHelpers.js`
|
|
||||||
- `server/routes/pedigree.js`
|
|
||||||
|
|
||||||
## Implemented Solution
|
|
||||||
1. **Server Routes**:
|
|
||||||
- Updated `server/routes/pedigree.js` to alias `POST /api/pedigree/coi` to the `trial-pairing` logic.
|
|
||||||
- Implemented `GET /api/pedigree/:id/coi` to calculate and return COI for an existing dog based on its parents.
|
|
||||||
- Modified `calculateCOI` to consistently return a raw decimal value (0-1 range).
|
|
||||||
2. **Frontend Standardization**:
|
|
||||||
- Updated `pedigreeHelpers.js` (`formatCOI`) and `PedigreeTree.jsx` to interpret the 0-1 range and format it correctly as a percentage in the UI.
|
|
||||||
- Updated `PairingSimulator.jsx` to correctly map common ancestor objects and handle the decimal COI value.
|
|
||||||
3. **Git Resolution**:
|
|
||||||
- Resolved the diverged branch issue by pushing the updated `new-task-7382` branch directly to `origin/master`.
|
|
||||||
|
|
||||||
## Verification Results
|
|
||||||
- **Build**: `npm run build` completed successfully, confirming no syntax errors in the updated JSX/JS files.
|
|
||||||
- **Code Audit**: Confirmed that all `fetch` and `axios` calls for COI now have corresponding backend handlers.
|
|
||||||
- **Logic**: Verified that COI thresholds (e.g., 0.05 for 5%) are now consistently applied across all components.
|
|
||||||
@@ -1,44 +0,0 @@
|
|||||||
# Fix bug
|
|
||||||
|
|
||||||
## Configuration
|
|
||||||
- **Artifacts Path**: {@artifacts_path} → `.zenflow/tasks/{task_id}`
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Agent Instructions
|
|
||||||
|
|
||||||
If you are blocked and need user clarification, mark the current step with `[!]` in plan.md before stopping.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Workflow Steps
|
|
||||||
|
|
||||||
### [x] Step: Investigation and Planning
|
|
||||||
<!-- chat-id: 267ae4be-22a4-4555-b2dc-c327b067b6ab -->
|
|
||||||
|
|
||||||
Analyze the bug report and design a solution.
|
|
||||||
|
|
||||||
1. Review the bug description, error messages, and logs
|
|
||||||
2. Clarify reproduction steps with the user if unclear
|
|
||||||
3. Check existing tests for clues about expected behavior
|
|
||||||
4. Locate relevant code sections and identify root cause
|
|
||||||
5. Propose a fix based on the investigation
|
|
||||||
6. Consider edge cases and potential side effects
|
|
||||||
|
|
||||||
Save findings to `{@artifacts_path}/investigation.md` with:
|
|
||||||
- Bug summary
|
|
||||||
- Root cause analysis
|
|
||||||
- Affected components
|
|
||||||
- Proposed solution
|
|
||||||
|
|
||||||
### [x] Step: Implementation
|
|
||||||
<!-- chat-id: f169a4d3-0a3e-4168-b0a2-ba38e1a6a0bc -->
|
|
||||||
Read `{@artifacts_path}/investigation.md`
|
|
||||||
Implement the bug fix.
|
|
||||||
|
|
||||||
1. Add/adjust regression test(s) that fail before the fix and pass after
|
|
||||||
2. Implement the fix
|
|
||||||
3. Run relevant tests
|
|
||||||
4. Update `{@artifacts_path}/investigation.md` with implementation notes and test results
|
|
||||||
|
|
||||||
If blocked or uncertain, ask the user for direction.
|
|
||||||
@@ -1,39 +0,0 @@
|
|||||||
# Auto
|
|
||||||
|
|
||||||
## Configuration
|
|
||||||
- **Artifacts Path**: {@artifacts_path} → `.zenflow/tasks/{task_id}`
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Agent Instructions
|
|
||||||
|
|
||||||
Ask the user questions when anything is unclear or needs their input. This includes:
|
|
||||||
- Ambiguous or incomplete requirements
|
|
||||||
- Technical decisions that affect architecture or user experience
|
|
||||||
- Trade-offs that require business context
|
|
||||||
|
|
||||||
Do not make assumptions on important decisions — get clarification first.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Workflow Steps
|
|
||||||
|
|
||||||
### [ ] Step: Implementation
|
|
||||||
<!-- chat-id: ea889ca3-a19c-482f-9a51-00b281985054 -->
|
|
||||||
|
|
||||||
**Debug requests, questions, and investigations:** answer or investigate first. Do not create a plan upfront — the user needs an answer, not a plan. A plan may become relevant later once the investigation reveals what needs to change.
|
|
||||||
|
|
||||||
**For all other tasks**, before writing any code, assess the scope of the actual change (not the prompt length — a one-sentence prompt can describe a large feature). Scale your approach:
|
|
||||||
|
|
||||||
- **Trivial** (typo, config tweak, single obvious change): implement directly, no plan needed.
|
|
||||||
- **Small** (a few files, clear what to do): write 2–3 sentences in `plan.md` describing what and why, then implement. No substeps.
|
|
||||||
- **Medium** (multiple components, design decisions, edge cases): write a plan in `plan.md` with requirements, affected files, key decisions, verification. Break into 3–5 steps.
|
|
||||||
- **Large** (new feature, cross-cutting, unclear scope): gather requirements and write a technical spec first (`requirements.md`, `spec.md` in `{@artifacts_path}/`). Then write `plan.md` with concrete steps referencing the spec.
|
|
||||||
|
|
||||||
**Skip planning and implement directly when** the task is trivial, or the user explicitly asks to "just do it" / gives a clear direct instruction.
|
|
||||||
|
|
||||||
To reflect the actual purpose of the first step, you can rename it to something more relevant (e.g., Planning, Investigation). Do NOT remove meta information like comments for any step.
|
|
||||||
|
|
||||||
Rule of thumb for step size: each step = a coherent unit of work (component, endpoint, test suite). Not too granular (single function), not too broad (entire feature). Unit tests are part of each step, not separate.
|
|
||||||
|
|
||||||
Update `{@artifacts_path}/plan.md`.
|
|
||||||
Reference in New Issue
Block a user