zman27/ai_ops
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

a

Browse Source
This commit is contained in:
Josh Rzemien
2026-02-24 18:57:45 -05:00
parent 7727612ce9
commit 90725eaae8
16 changed files with 263 additions and 761 deletions
Download Patch File Download Diff File Expand all files Collapse all files

264
human_only_TODO
View File

@@ -10,21 +10,137 @@
# in progress
there is some major ui issue. there is app/provider logic wrapped up in the ui which i didnt know about or understand and it has gotten out of hand. we need to rip it out and clean it up. additionally the work trees are still not working as intended after like 5 attempts to fix it so that has got to be officially spaghetti at this point
here is the takeaway from the ui app logic issue
- Keep orchestration core in src/agents.
- Move backend run/session/provider code out of src/ui into src/control-plane (or src/backend).
- Keep src/ui as static/frontend + API client only.
- Treat provider prompt shaping as an adapter concern (src/providers), not UI concern.
test results
session itself has a dir in worktrees that is a worktree
then there is a base dir and a tasks dir
base is also a worktree
inside of base, there is ANOTHER WORKTREE
inside of tasks is a product-intake??? directory
code is being written in both product-intake and the worktree in the base/worktrees/d3e411... directory
i dont think that the product guy is writing any files
fwiw, the dev agents are definitely making the app
log activity of claude code binary
WHY IS IT STILL NOT LOGGING WHAT IS ACTUALLY HAPPENING
it will not explain it, it just keeps adding different logs
test run
they are writing files!
# problem 1 - logging
logging is still fucking dog dick fuck ass shit
# problem 2 - worktree
the worktree shit is fucking insanity
they are getting confused because they see some of the orchestration infrastructure
they legit need to be in a clean room and know nothing about the world outside of their project going forward
# problem 3 - task management/product context being passed in its entirety
the dev agents for some reason have the entire fucking task list in their context
# Scheduled
So yes, the UI growing into “its own project” increases risk because orchestration logic leaks into UI-layer
services.
Best refactor target:
1. Make UI a thin transport layer (HTTP in/out, no resource ownership decisions).
2. Move run/session orchestration into one app-service module with a strict interface.
3. Enforce single-owner invariants in code (worktree owner = session lifecycle only).
4. Add contract tests around ownership boundaries (like the regression we just added).
what even is src/examples ????
clean up events/locks/ports (may not be needed with new session work?)
ui is gargantuan - needs a full rewrite in a different dir or something holy
the ais arent actually writing to the directory
the ui is fucking bad
it kinda slow
i think the banned command thing is kind of restrictive, idk if they will really be able to do anything
codex isnt working?
i dont even know if this runs on linux at all
wtf is even happening in the backend i dont see any logs for it anywhere
# identify potential design conflict dag vs things that happen not on the dag?
## linked to confusion around max env vars and what they do
- "This runtime enforces a DAG, so merge-conflict retry loops are multi-run (rerun the same managed session) rather than in-run graph cycles."
- what are the implications of this? is this a stop gap until we do stricter control at the ends (task manager + git worktree cleanup)? or do we have a design inconsistency that we need to address?
For structured-dev-workflow specifically
- Happy path is depth 4 (product -> task -> dev -> qa -> merge).
- QA-fail/rework path reaches depth ~6.
- If merge-conflict resolver nodes are used, path can reach ~7.
# confusion around max env vars and what they do
## linked to identify potential design conflict dag vs things that happen not on the dag?
PROBLEM
.env has AGENT_MAX_RECURSIVE_DEPTH=3, but structured-dev-workflow requires depth 4 (product -> task -> dev -> qa -> merge)
- does this mean that if qa sends a task back to dev that the depth is 5? or does it literally mean num of agents in a branch of the dag?
- if it blocks, problem because it will just fail if we have to pass back
- if it doesnt, problem bc this does nothing - we are either allowing them to loop infinitely creating themselves OR we are relying on enforcing that elsewhere and we need to consolidated
RESPONSE
• Short answer: your concern is valid, and today the two depth limits are conflated more than they should be.
1. Does QA -> Dev make depth 5?
- In this system, depth is not “number of unique agents.” It is path depth from the entry node (edge distance), plus recursive child depth when retries/fanout happen.
- Back-edges like qa -> dev to the same upstream node are not allowed because pipeline must be a strict DAG (manifest.ts (/home/zman/projects/ai_ops/src/agents/manifest.ts)).
- So “send back” is modeled as downstream rework nodes (qa -> dev-rework -> qa-rework -> merge), which does increase depth.
2. If it blocks, that’s bad; if not, does the limit do nothing?
- It does block today, and it also does still serve a purpose.
- PipelineExecutor increments node depth by edge traversal (pipeline.ts (/home/zman/projects/ai_ops/src/agents/pipeline.ts:748), pipeline.ts (/home/zman/projects/ai_ops/src/agents/pipeline.ts:815)).
- But that same depth is passed into AgentManager.runRecursive (pipeline.ts (/home/zman/projects/ai_ops/src/agents/pipeline.ts:875)), and AgentManager enforces maxRecursiveDepth on that depth (manager.ts (/home/zman/projects/ai_ops/
src/agents/manager.ts:343)).
- So AGENT_MAX_RECURSIVE_DEPTH is currently acting as a second pipeline-depth cap, not just a recursion cap.
For structured-dev-workflow specifically
- Happy path is depth 4 (product -> task -> dev -> qa -> merge).
- QA-fail/rework path reaches depth ~6.
- If merge-conflict resolver nodes are used, path can reach ~7.
- So with .env values like AGENT_MAX_RECURSIVE_DEPTH=3 and AGENT_TOPOLOGY_MAX_DEPTH=4, fallback branches will fail.
SOLUTION
2. Structural fix (better):
- Decouple meanings:
- AGENT_TOPOLOGY_MAX_DEPTH should gate DAG traversal depth only.
- AGENT_MAX_RECURSIVE_DEPTH should gate recursive fanout/retry depth only.
- In practice: stop passing pipeline queue depth into manager recursive depth; start recursive runs at a local depth baseline per node.
3. Safety/clarity guard:
- Add a preflight check that computes max possible DAG depth and warns/errors if env depth limits are below it.
# other scheduled
- persona definitions
@@ -555,4 +671,150 @@ Manifest Builder: A UI to visually build or edit the AgentManifest (Schema "1"),
Security Policy Management: An interface mapped to src/security/schemas.ts. This allows admins to define AGENT_SECURITY_ALLOWED_BINARIES, toggle AGENT_SECURITY_VIOLATION_MODE (hard_abort vs validation_fail), and manage MCP tool allowlists/banlists.
Environment & Resource Limits: Simple forms to configure agent manager limits (AGENT_MAX_CONCURRENT) and port block sizing without manually editing the .env file.
Environment & Resource Limits: Simple forms to configure agent manager limits (AGENT_MAX_CONCURRENT) and port block sizing without manually editing the .env file.
# Architecture Requirements: Session Isolation & Task-Scoped Worktrees
## Objective
Disentangle the `ai_ops` control plane from the target project data plane. Replace the implicit `process.cwd()` execution anchor with a formal Session lifecycle and dynamic, task-scoped Git worktrees. This ensures concurrent agents operate in isolated environments and prevents the runtime from mutating its own repository.
## 1. Domain Definitions
- **Target Project:** The absolute local path to the repository being operated on (e.g., `/home/user/target_repo`).
- **Session (The Clean Room):** A persistent orchestration context strictly bound to one Target Project. It maintains a "Base Workspace" (a localized Git checkout/branch) that represents the integrated, approved state of the current work period.
- **Task Worktree:** An ephemeral Git worktree branched from the Session's Base Workspace. It is scoped strictly to a `taskId`, enabling multi-agent handoffs (e.g., Coder $\rightarrow$ QA) within the same isolated environment before merging back to the Base Workspace.
## 2. Core Data Model Updates
Introduce explicit types to track project binding and resource ownership.
- **API Payloads:**
TypeScript
```
interface CreateSessionRequest {
projectPath: string; // Absolute local path to target repo
}
```
- **Session State (`AGENT_STATE_ROOT`):**
TypeScript
```
interface SessionMetadata {
sessionId: string;
projectPath: string;
sessionStatus: 'active' | 'suspended' | 'closed';
baseWorkspacePath: string; // e.g., ${AGENT_WORKTREE_ROOT}/${sessionId}/base
createdAt: string;
updatedAt: string;
}
```
- **Project Context (`src/agents/project-context.ts`):**
Update the `taskQueue` schema to act as the persistent ledger for worktree ownership.
TypeScript
```
interface TaskRecord {
taskId: string;
status: 'pending' | 'in_progress' | 'review' | 'merged' | 'failed';
worktreePath?: string; // e.g., ${AGENT_WORKTREE_ROOT}/${sessionId}/tasks/${taskId}
}
```
## 3. API & Control Plane (`src/ui/server.ts`)
Replace implicit session generation with an explicit lifecycle API.
- `POST /api/sessions`: Accepts `CreateSessionRequest`. Initializes the SessionMetadata and provisions the Base Workspace.
- `GET /api/sessions`: Returns existing sessions for resuming work across restarts.
- `POST /api/sessions/:id/run`: Triggers `SchemaDrivenExecutionEngine.runSession(...)`, passing the resolved `SessionMetadata`.
- `POST /api/sessions/:id/close`: Prunes all task worktrees, optionally merges the Base Workspace back to the original `projectPath`, and marks the session closed.
## 4. Provisioning Layer (`src/agents/provisioning.ts`)
Remove all fallback logic relying on `process.cwd()`.
- **Session Initialization:** Clone or create a primary worktree of `projectPath` into `baseWorkspacePath`.
- **Task Provisioning:** When a task begins execution, check out a new branch from the Base Workspace and provision it at `worktreePath`.
- **Security & MCP Isolation:** `SecureCommandExecutor` and MCP handler configurations must dynamically anchor their working directories to the specific `worktreePath` injected into the execution context, preventing traversal outside the task scope.
## 5. Orchestration & Routing (`src/agents/pipeline.ts`)
Implement the hybrid routing model: Domain Events for control flow, Project Context for resource lookup.
1. **The Signal (Domain Events):** When a Coder agent finishes, it emits a standard domain event (e.g., `task_ready_for_review` with the `taskId`). The pipeline routes this event to trigger the QA agent.
2. **The Map (Project Context):** Before initializing the QA agent's sandbox, the lifecycle observer/engine reads `project-context.ts` to look up the `worktreePath` associated with that `taskId`.
3. **The Execution:** The QA agent boots inside the exact same Task Worktree the Coder agent just vacated, preserving all uncommitted files and local state.
4. **The Merge:** Upon successful QA (e.g., `validation_passed`), the orchestration layer commits the Task Worktree, merges it into the Base Workspace, and deletes the Task Worktree.
# turning merge conflicts into first-class orchestration events instead of hard exceptions.
1. Add new domain events:
- merge_conflict_detected
- merge_conflict_resolved
- merge_conflict_unresolved (after max attempts)
- optionally merge_retry_started
2. Extend task state model with conflict-aware statuses:
- add conflict (and maybe resolving_conflict)
3. Change merge code path to return structured outcomes instead of throwing on conflict:
- success
- conflict (with conflictFiles, mergeBase, taskId, worktreePath)
- fatal_error
- only throw for truly fatal cases (repo corruption, missing worktree, etc.)
4. On conflict, patch project context + emit event:
- set task to conflict
- store conflict metadata in task.metadata
- emit merge_conflict_detected
5. Route conflict events to dedicated resolver personas in the pipeline:
- Coder/QA conflict-resolver agent opens same worktreePath
- resolves conflict markers, runs checks
- emits merge_conflict_resolved
6. Retry merge after resolution event:
- integration node attempts merge again
- if successful, emit branch_merged, mark merged, prune task worktree
- if still conflicting, loop with bounded retries
7. Add retry guardrails:
- max conflict-resolution attempts per task
- on exhaustion emit merge_conflict_unresolved and stop cleanly (not crash the whole session)
8. Apply same pattern to session close (base -> project) so close can become:
- conflict workflow or “closed_with_conflicts” state, rather than a hard failure.
This keeps the app stable and lets agents handle conflicts as part of normal orchestration.