feat(system): S67 APLAN template, stale file cleanup (#158)

* feat(system): S66 test: DPLAN-0088 live verification of auto status sync

Co-Authored-By: @devpulse <devpulse@aipass>

* feat(system): APLAN template, all-caps cleanup, stale file removal

- Register APLAN (audit plan) template in flow for branch audits
- Remove all-caps emphasis from DPLAN, FPLAN, RPLAN templates
- Add no-all-caps rule to global prompt Hard Rules
- Strengthen FPLAN close instruction (clearer, final step)
- Clean up stale tracked files (.plans_processed.json, test file)
- Update .gitignore and settings.local.json

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: @devpulse <devpulse@aipass>
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
AIPass
2026-03-31 00:41:04 -07:00
committed by GitHub
co-authored by Claude Opus 4.6 @devpulse
parent 47e3088a1b
commit 651bc6a94e
8 changed files with 164 additions and 51 deletions
+4 -3
View File
@@ -96,17 +96,17 @@ drone @ai_mail dispatch wake --fresh @target
## Logging & Debugging
Prax is the ONLY logging system. Every branch uses:
Prax is the **only** logging system. Every branch uses:
```python
from aipass.prax import logger
```
Two output channels — know the difference:
- **Console** = what the user sees right now. Command results, errors, success messages. If something fails, the user MUST see it in the console — never fail silently. Use CLI console output for real-time feedback.
- **Console** = what the user sees right now. Command results, errors, success messages. If something fails, the user **must** see it in the console — never fail silently. Use CLI console output for real-time feedback.
- **Prax logs** = what gets written to your `logs/` directory. Operational history for after-the-fact debugging — what resolved, what path was taken, what failed and why. Use `logger.info()`, `logger.warning()`, `logger.error()`.
**Errors go to BOTH.** Console tells the user something broke. Log tells you (or the next session) what happened and why.
**Errors go to both.** Console tells the user something broke. Log tells you (or the next session) what happened and why.
**Your logs are your first diagnostic tool.** When something unexpected happens — a command fails, output looks wrong, behavior doesn't match — check your `logs/` before trying anything else. The answer is usually already there. Other branches' logs are in their own `logs/` directories — you can read those too if you need to trace cross-branch behavior. Don't write debug scripts, don't add print statements — read your logs.
@@ -151,6 +151,7 @@ If the conversation suddenly shifts to a topic, project, or domain that doesn't
- **Cross-platform.** AIPass is a public package — code must work on Linux, macOS, and Windows. Use `pathlib.Path` not string concatenation. Use `Path.home()` not `~` or `/home/`. Secrets live at `~/.secrets/aipass/` (`Path.home() / ".secrets" / "aipass"`).
- **Public repo — no local paths in code.** Never hardcode `/home/username/...` or any machine-specific path. All file paths must derive from `Path(__file__)`, `Path.home()`, or registry lookups. This repo is public — your local directory structure doesn't exist for anyone else. Tests included.
- **Fail to errors, never fall back silently.** When a command, handler, or module receives input it can't handle, return an explicit error — not a silent fallback to default output. No dimming, no swallowing, no showing the same screen regardless of input. The user must see that their input was received and rejected. Show what's missing (no help available, no introspection, no subcommands) and where to look (file path). Dead ends must announce themselves.
- **Never use all caps for emphasis in prompts, templates, or instructions.** All caps reads as shouting and AI agents tend to deprioritize or ignore all-caps instructions. Use bold, italics, or clear phrasing instead. This applies everywhere: branch prompts, plan templates, dispatch emails, global prompt, README files.
## Memories
+16 -19
View File
@@ -2,7 +2,7 @@
> Auto-generated by `drone @prax status sync`. Do not edit manually.
**Last sync:** 2026-03-30 22:28
**Last sync:** 2026-03-30 22:51
**Summary:** 9 operational | 0 in-progress | 0 not started
---
@@ -251,14 +251,14 @@ Removed `_module` suffix from all 21 module files per seedgo naming standard ("P
</details>
<details><summary><strong>@devpulse</strong> — Operational (2026-03-28)</summary>
<details><summary><strong>@devpulse</strong> — Operational (2026-03-30)</summary>
# @devpulse
> Orchestration hub — coordinates via dispatch + agents (no apps/)
**State:** Operational
**Last update:** 2026-03-28
**Last update:** 2026-03-30
## Milestones
- 58 sessions of system coordination
@@ -331,22 +331,19 @@ Removed `_module` suffix from all 21 module files per seedgo naming standard ("P
## Notepad
> **SCRATCH SPACE — gets wiped at session start or topic change.**
Session 65 (Night Shift):
- FPLAN-0154 COMPLETE: 14 branches dispatched across 3 phases, all replied successfully
- Phase 1 (critical): backup dry-run, ai_mail per-ID, flow introspection gate, drone atomic writes, commons 3-strategy detection
- Phase 2 (patterns): spawn argparse+dry-run, skills create help, api introspection routing, trigger empty JSON, seedgo @ prefix
- Phase 3 (polish): prax ghost module archived, daemon update+error cascade, memory search timeout, cli standalone verified
- Phase 4 (verification): 3,410 tests (+80), seedgo 99% avg, 0 failures
- Key pattern: introspection fallback (no-args gate before routing) was root cause across flow, api, daemon, prax
- Prax conftest.py updated: collect_ignore_glob for .archive/
Session 65 (continued — master key):
- DPLAN-0087: devpulse_ops plugin suite complete. 4 plugins: system-pr, merge, smart-sync, fix
- Full test suite: 8/8 scenarios passed (PRs #147-153, all merged, repo clean)
- system-pr + merge cycle is the new standard workflow for system-wide PRs
- Phase 3 (snapshot_handler) designed in DPLAN but not built — handler not plugin
- FPLAN-0154 still open (can close now — all phases done)
- PR #146 (HERALD) merged during night shift sequence
- Next: update prompts/docs with new commands, build snapshot_handler, Patrick author mode
Session 66:
- Synrix/Octopoda research: analyzed external memory engine (16k LOC), created RPLAN template + RPLAN-0001
- RPLAN template registered: `drone @flow create <path> "subject" rplan` for external repo research
- Denied git add -f system-wide (settings.json) — gitignore boundaries must never be bypassed
- DPLAN-0087 force-added file removed from tracking (git rm --cached)
- RPLAN-*.md added to .gitignore
- DPLAN-0088: Auto STATUS.md sync on PR create/merge — trigger built pr_created + pr_merged events, drone wired trigger.fire() into all 3 PR handlers
- Global prompt updated: compaction anxiety removed, Patrick controls compaction manually
- inotify limits bumped (512 instances, 524k watches)
- Flow dashboard push failure fixed, timestamp parsing issue dispatched
- PRs #154 (RPLAN + gitignore), #155 (auto-sync + global prompt)
- Waiting: PR #154+#155 merge, then live test of auto STATUS.md sync
- TEST: DPLAN-0088 live verification — this line triggers status sync
</details>
@@ -1,11 +1,17 @@
{
"permissions": {
"allow": [
"Bash(gh pr create*)"
],
"allow": [],
"deny": [
"Bash(git reset*)",
"Bash(git rebase*)",
"Bash(git merge*)",
"Bash(git config*)",
"Bash(git push --force*)",
"Bash(git push -f *)",
"Bash(git checkout -- *)",
"Bash(git checkout .*)",
"Bash(git restore --staged*)",
"Bash(git restore .*)",
"Bash(git clean*)",
"Bash(git branch -D*)",
"Bash(git stash drop*)",
@@ -14,8 +20,7 @@
"Bash(rm -r *)",
"Bash(git checkout -b*)",
"Bash(git commit*)",
"Bash(git push*)",
"Bash(gh pr close*)"
"Bash(git push*)"
],
"ask": []
},
@@ -1 +0,0 @@
# Test file for system-pr plugin verification\nCreated: Mon Mar 30 01:57:37 PM PDT 2026\nThis file can be safely deleted.
@@ -0,0 +1,108 @@
# {plan_number}: {subject}
Tag: audit, branch-audit, {tag}
> Branch audit for @{tag} -- living document tracking health, issues, and improvements
---
## What is an APLAN?
Audit Plans (APLANs) are **living documents** -- they track the ongoing health, issues, and improvements for a specific branch. Unlike DPLANs (which capture a moment of thinking) or FPLANs (which track a build), APLANs persist across sessions and grow as the branch evolves.
**This IS for:**
- Recording branch health status and key metrics
- Tracking bugs, issues, and improvement opportunities as they're discovered
- Logging what's been dispatched and the results
- Maintaining a clear picture of what's open vs resolved
- Serving as working memory for the next time we touch this branch
**This is NOT for:**
- Building code -- that's an FPLAN
- One-off design thinking -- that's a DPLAN
- Quick fixes -- just do those directly
**APLANs are never trimmed and rarely closed.** They accumulate history. When a branch gets a major overhaul, start a fresh APLAN and archive the old one.
**Keep items current.** Check boxes when work is done. Add new issues as they're found. Update the metrics when you verify. This document should always reflect reality.
---
## Quick Status
| Metric | Value |
|--------|-------|
| **Health** | GREEN / YELLOW / RED |
| **Last verified** | {today} |
| **Open items** | 0 |
| **Tests** | 0 pass, 0 fail |
| **Seedgo** | 0% (0 standards) |
| **Bypass entries** | 0 |
| **CLI score** | Nav 0/5, Output 0/5 |
## Current State
### Summary
- Key facts about the branch
### Architecture
Brief description of how the branch is structured and what it does.
### What Works Well
- Things that are solid and don't need attention
## Issues Found
### Open
Use checkboxes. Mark resolved items with `[x]` and note which session resolved them.
- [ ] Issue description -- context and impact
### Resolved
- [x] Example resolved issue (S00 -- brief note on how it was fixed)
## What Needs Doing
### For @{tag} to handle (dispatch)
Items that require the branch itself to fix.
- [ ] Item description
### For devpulse to handle
Items that devpulse coordinates or fixes directly.
- [ ] Item description
### Tracked elsewhere
Items captured in other DPLANs or FPLANs.
- [ ] Item description -- see DPLAN-XXXX
## Dispatch Log
| Date | Action | Result |
|------|--------|--------|
| {today} | Initial audit | Pending |
## Relationships
- **Related DPLANs:** None yet
- **Related FPLANs:** None yet
- **Owner branch:** @{tag}
- **Seedgo:** `drone @seedgo audit aipass @{tag}`
## Notes
Session notes, discoveries, changes. Stamp each entry with session number and date.
**S00 ({today}):** Initial audit created.
## Listen (TTS-friendly summary)
Write a plain English summary of this audit here. No markdown, no symbols, no tables, no code blocks, no asterisks, no bullet points. Just natural sentences that can be read aloud by a text to speech tool. Cover the branch health, key open issues, and what needs attention next. Update this section whenever the audit changes significantly.
Last verified {today}.
---
*Created: {today}*
*Updated: {today}*
@@ -8,7 +8,7 @@ Tag: {tag}
## What is a DPLAN?
Design Plans (DPLANs) are for **THINKING** -- capturing ideas, brainstorming, investigating, planning, and making decisions. They are the space where conversations, research, and design work get written down so they can be reclaimed later.
Design Plans (DPLANs) are for **thinking** -- capturing ideas, brainstorming, investigating, planning, and making decisions. They are the space where conversations, research, and design work get written down so they can be reclaimed later.
**This IS for:**
- Capturing an idea or concept worth exploring
+23 -20
View File
@@ -9,7 +9,7 @@
## What Are Flow Plans?
Flow Plans (FPLANs) are for **BUILDING** - autonomous construction of systems, features, modules.
Flow Plans (FPLANs) are for **building** - autonomous construction of systems, features, modules.
**FPLANs are disposable.** They exist for exactly one task. When the task is complete, close this plan immediately — do not leave it open. Open FPLANs mean unfinished work. If the work is done, the plan is done: `drone @flow close {plan_number}`
@@ -54,9 +54,9 @@ Use dedicated directories - don't scatter files:
## Critical: Branch Manager Role
**You are the ORCHESTRATOR, not the builder.**
**You are the orchestrator, not the builder.**
Your 200k context is precious. Burning it on file reads and code writing risks compaction during autonomous work. Agents have clean context - use them for ALL building.
Your 200k context is precious. Burning it on file reads and code writing risks compaction during autonomous work. Agents have clean context - use them for all building.
| You Do (Orchestrator) | Agents Do (Builders) |
|-----------------------|----------------------|
@@ -151,15 +151,15 @@ Agents can't work blind. They need context before they build.
1. [ ] Know where agent will work (branch path, key directories)
2. [ ] Identify files agent needs to reference or modify
3. [ ] Gather any specs, planning docs, or examples to include
4. [ ] Prepare COMPLETE instructions (agents are stateless)
4. [ ] Prepare complete instructions (agents are stateless)
**Agent's First Task (context building):**
- Agent should explore/read relevant files BEFORE writing code
- Agent should explore/read relevant files before writing code
- "First, read X and Y to understand the current structure"
- "Look at Z for the pattern to follow"
- Context-first, build-second
**What Agents DON'T Have:**
**What agents don't have:**
- No prior conversation history
- No memory files loaded automatically
- No knowledge of other branches
@@ -171,28 +171,28 @@ Agents can't work blind. They need context before they build.
## Agent Instructions Template
```
You are working at [BRANCH_PATH].
You are working at [branch_path].
TASK: [Specific single task]
**Task:** [Specific single task]
CONTEXT:
**Context:**
- [What they need to know]
- Reference: [planning docs, existing code to study]
- First, READ the relevant files to understand current structure
- First, read the relevant files to understand current structure
DELIVERABLES:
**Deliverables:**
- [Specific file or output expected]
- Tests -> tests/
- Reports/logs -> artifacts/reports/ or artifacts/logs/
CONSTRAINTS:
**Constraints:**
- Follow Seedgo standards (3-layer architecture)
- Do NOT modify files outside your task scope
- CROSS-BRANCH: Never modify other branches' files unless explicitly authorized by the user
- 2-ATTEMPT RULE: If something fails twice, note the issue and move on
- Do NOT go down rabbit holes debugging
- Do not modify files outside your task scope
- Cross-branch: never modify other branches' files unless explicitly authorized by the user
- Two-attempt rule: if something fails twice, note the issue and move on
- Do not go down rabbit holes debugging
WHEN COMPLETE:
**When complete:**
- Verify code runs without syntax errors
- List files created/modified
- Note any issues encountered (with what was attempted)
@@ -213,7 +213,7 @@ WHEN COMPLETE:
**If production stops (critical blocker):**
```bash
drone @ai_mail email @devpulse "PRODUCTION STOPPED: {plan_number}" "Issue: [description]. Attempted: [what was tried]. Awaiting guidance."
drone @ai_mail email @devpulse "Production stopped: {plan_number}" "Issue: [description]. Attempted: [what was tried]. Awaiting guidance."
```
---
@@ -253,9 +253,12 @@ Write a plain English summary of this plan here. No markdown, no symbols, no tab
---
## Close Command
## Close This Plan
**This is your final step.** When all goals are achieved and the completion checklist above is done, close this plan. Do not leave it open. An open plan means unfinished work.
When all boxes checked:
```bash
drone @flow close {plan_number}
```
If you are an agent finishing the last task in this plan, close it yourself before your session ends. If you are the orchestrator reviewing agent output, close it once verified. Someone must close it — plans do not close themselves.
@@ -8,9 +8,9 @@ Tag: research, external-repo, {tag}
## What is an RPLAN?
Research Plans (RPLANs) are for **STUDYING EXTERNAL WORK** -- analyzing repos, packages, libraries, and projects to extract patterns, ideas, and lessons that could benefit AIPass.
Research Plans (RPLANs) are for **studying external work** -- analyzing repos, packages, libraries, and projects to extract patterns, ideas, and lessons that could benefit AIPass.
**This IS for:**
**This is for:**
- Analyzing an external repo or pip package
- Documenting architecture, patterns, and design decisions found
- Identifying what AIPass could learn from or adapt