Compare commits
2 Commits
76e263c0c9
...
a70e4e2b21
| Author | SHA1 | Date | |
|---|---|---|---|
| a70e4e2b21 | |||
| ce75f0e5a1 |
@@ -11,3 +11,8 @@ This file tracks all major tracks for the project. Each track has its own detail
|
||||
|
||||
- [ ] **Track: Review vendor api usage in regards to conservative context handling**
|
||||
*Link: [./tracks/api_metrics_20260223/](./tracks/api_metrics_20260223/)*
|
||||
|
||||
---
|
||||
|
||||
- [ ] **Track: Update conductor to properly utilize the new api hooks for automated testing & verification of track implementation features withou the need of user intervention.**
|
||||
*Link: [./tracks/api_hooks_verification_20260223/](./tracks/api_hooks_verification_20260223/)*
|
||||
|
||||
@@ -0,0 +1,5 @@
|
||||
# Track api_hooks_verification_20260223 Context
|
||||
|
||||
- [Specification](./spec.md)
|
||||
- [Implementation Plan](./plan.md)
|
||||
- [Metadata](./metadata.json)
|
||||
@@ -0,0 +1,8 @@
|
||||
{
|
||||
"track_id": "api_hooks_verification_20260223",
|
||||
"type": "feature",
|
||||
"status": "new",
|
||||
"created_at": "2026-02-23T17:46:51Z",
|
||||
"updated_at": "2026-02-23T17:46:51Z",
|
||||
"description": "Update conductor to properly utilize the new api hooks for automated testing & verification of track implementation features without the need of user intervention."
|
||||
}
|
||||
@@ -0,0 +1,19 @@
|
||||
# Implementation Plan: Integrate API Hooks for Automated Track Verification
|
||||
|
||||
## Phase 1: Update Workflow Definition
|
||||
- [ ] Task: Modify `conductor/workflow.md` to reflect the new automated verification process.
|
||||
- [ ] Sub-task: Update the "Phase Completion Verification and Checkpointing Protocol" section to replace manual verification steps with a description of the automated API hook process.
|
||||
- [ ] Sub-task: Ensure the updated workflow clearly states that the agent will announce the automated test, execute it, and then present the results (success or failure) to the user.
|
||||
- [ ] Task: Conductor - User Manual Verification 'Phase 1: Update Workflow Definition' (Protocol in workflow.md)
|
||||
|
||||
## Phase 2: Implement Automated Verification Logic
|
||||
- [ ] Task: Develop the client-side logic for communicating with the API hook server.
|
||||
- [ ] Sub-task: Write failing unit tests for a new `ApiHookClient` that can send requests to the IPC server.
|
||||
- [ ] Sub-task: Implement the `ApiHookClient` to make the tests pass.
|
||||
- [ ] Task: Integrate the `ApiHookClient` into the Conductor agent's workflow.
|
||||
- [ ] Sub-task: Write failing integration tests to ensure the Conductor's phase completion logic calls the `ApiHookClient`.
|
||||
- [ ] Sub-task: Modify the workflow implementation to use the `ApiHookClient` for verification.
|
||||
- [ ] Task: Implement result handling and user feedback.
|
||||
- [ ] Sub-task: Write failing tests for handling success, failure, and server-unavailable scenarios.
|
||||
- [ ] Sub-task: Implement the logic to log results, present them to the user, and halt the workflow on failure.
|
||||
- [ ] Task: Conductor - User Manual Verification 'Phase 2: Implement Automated Verification Logic' (Protocol in workflow.md)
|
||||
@@ -0,0 +1,21 @@
|
||||
# Specification: Integrate API Hooks for Automated Track Verification
|
||||
|
||||
## Overview
|
||||
This track focuses on integrating the existing, previously implemented API hooks (from track `test_hooks_20260223`) into the Conductor workflow. The primary goal is to automate the verification steps within the "Phase Completion Verification and Checkpointing Protocol", reducing the need for manual user intervention and enabling a more streamlined, automated development process.
|
||||
|
||||
## Functional Requirements
|
||||
- **Workflow Integration:** The `workflow.md` document, specifically the "Phase Completion Verification and Checkpointing Protocol," must be updated to replace manual verification steps with automated checks using the API hooks.
|
||||
- **IPC Communication:** The updated workflow will communicate with the application's backend via the established IPC server to trigger verification tasks.
|
||||
- **Result Handling:**
|
||||
- All results from the API hook verifications must be logged for auditing and debugging purposes.
|
||||
- Upon successful verification, the Conductor agent will proceed with the workflow as it currently does after a successful manual check.
|
||||
- Upon failure, the agent will halt, present the failure logs to the user, and await further instructions.
|
||||
- **User Interaction Model:** The system will transition from asking the user to perform a manual test to informing the user that an automated test is running, and then presenting the results.
|
||||
|
||||
## Non-Functional Requirements
|
||||
- **Resilience:** The Conductor agent must handle cases where the API hook server is unavailable or a hook call fails unexpectedly, without crashing or entering an unrecoverable state.
|
||||
- **Transparency:** All interactions with the API hooks must be clearly logged, making the automated process easy to monitor and debug.
|
||||
|
||||
## Out of Scope
|
||||
- **Modifying API Hooks:** This track will not alter the existing API hooks, the IPC server, or the backend implementation. The focus is solely on the client-side integration within the Conductor agent's workflow.
|
||||
- **Changes to Manual Overrides:** Users will retain the ability to manually intervene or bypass automated checks if necessary.
|
||||
@@ -1,5 +0,0 @@
|
||||
# Track test_hooks_20260223 Context
|
||||
|
||||
- [Specification](./spec.md)
|
||||
- [Implementation Plan](./plan.md)
|
||||
- [Metadata](./metadata.json)
|
||||
@@ -1,8 +0,0 @@
|
||||
{
|
||||
"track_id": "test_hooks_20260223",
|
||||
"type": "feature",
|
||||
"status": "new",
|
||||
"created_at": "2026-02-23T10:00:00Z",
|
||||
"updated_at": "2026-02-23T10:00:00Z",
|
||||
"description": "Add full api/hooks so that gemini cli can test, interact, and manipulate the state of the gui & program backend for automated testing."
|
||||
}
|
||||
@@ -1,25 +0,0 @@
|
||||
# Implementation Plan
|
||||
|
||||
## Phase 1: Foundation and Opt-in Mechanisms [checkpoint: 2bc7a3f]
|
||||
- [x] Task: Implement CLI flag/env-var to enable the hook system [1306163]
|
||||
- [x] Sub-task: Write Tests
|
||||
- [x] Sub-task: Implement Feature
|
||||
- [x] Task: Set up lightweight local IPC server (e.g., standard library socket/HTTP) for receiving hook commands [44c2585]
|
||||
- [x] Sub-task: Write Tests
|
||||
- [x] Sub-task: Implement Feature
|
||||
- [x] Task: Conductor - User Manual Verification 'Phase 1: Foundation and Opt-in Mechanisms' (Protocol in workflow.md) [2bc7a3f]
|
||||
|
||||
## Phase 2: Hook Implementations and Logging [checkpoint: eaf229e]
|
||||
- [x] Task: Implement project and AI session state manipulation hooks [d9d056c]
|
||||
- [x] Sub-task: Write Tests
|
||||
- [x] Sub-task: Implement Feature
|
||||
- [x] Task: Implement GUI state manipulation hooks with thread-safe queueing [5f9bc19]
|
||||
- [x] Sub-task: Write Tests
|
||||
- [x] Sub-task: Implement Feature
|
||||
- [x] Task: Integrate aggressive logging for all hook invocations [ef29902]
|
||||
- [x] Sub-task: Write Tests
|
||||
- [x] Sub-task: Implement Feature
|
||||
- [x] Task: Conductor - User Manual Verification 'Phase 2: Hook Implementations and Logging' (Protocol in workflow.md) [eaf229e]
|
||||
|
||||
## Phase: Review Fixes
|
||||
- [x] Task: Apply review suggestions [dc64493]
|
||||
@@ -1,21 +0,0 @@
|
||||
# Specification: Add full api/hooks so that gemini cli can test, interact, and manipulate the state of the gui & program backend for automated testing
|
||||
|
||||
## Overview
|
||||
This track introduces a comprehensive suite of API hooks designed specifically for the Gemini CLI and the Conductor framework. These hooks will allow automated agents to manipulate and test the internal state of the application without requiring manual GUI interaction, enabling automated test-driven development and track progression validation.
|
||||
|
||||
## Use Cases
|
||||
- **Automated Testing & Progression:** Expose low-level state manipulation hooks so that the Gemini CLI + Conductor can autonomously verify track completion, test UI logic, and validate backend states.
|
||||
|
||||
## Functional Requirements
|
||||
- **Comprehensive Access:** The hooks must provide full, unrestricted access to the entire program, including:
|
||||
- GUI state (Dear PyGui nodes, values, layout data).
|
||||
- AI session state (history, active caches, tool configurations).
|
||||
- Project configurations and discussion state.
|
||||
- **Security & Logging:** The hook system MUST be strictly opt-in (e.g., enabled via a specific command-line argument like `--enable-test-hooks` or an environment variable). When enabled, any invocation of these hooks MUST be aggressively logged to ensure transparency.
|
||||
|
||||
## Non-Functional Requirements
|
||||
- **Thread Safety:** Hooks interacting with the GUI state must respect the main render loop locks and threading model defined in the architecture guidelines.
|
||||
- **Dependency Minimalism:** The hook interface should utilize built-in mechanisms (like sockets, a lightweight local HTTP server, or standard inter-process communication) without introducing heavy external web frameworks.
|
||||
|
||||
## Out of Scope
|
||||
- Building the actual Gemini CLI or Conductor automation logic itself; this track only builds the *hooks* within Manual Slop that those external agents will consume.
|
||||
Reference in New Issue
Block a user