fix: Remove YAML usage, standardize on JSON/TOML
- Delete 5 legacy .formula.yaml files (have .toml replacements) - Remove unused FileConfigYAML constant - Add TODO for beads config.yaml → config.json migration (bd-10wg) - Update docs to use JSON examples instead of yaml code blocks - Change plugin frontmatter from YAML to TOML in docs - Add .toml to code file detection in branch_check.go 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
This commit is contained in:
gastown/crew/gus
committed by
Steve Yegge
Steve Yegge
parent
cc3622117e
commit
f75eeb4da8
@@ -323,7 +323,7 @@ needs = ["health-scan"]
|
||||
description = """
|
||||
Execute registered plugins.
|
||||
|
||||
Scan ~/gt/plugins/ for plugin directories. Each plugin has a plugin.md with YAML frontmatter defining its gate (when to run) and instructions (what to do).
|
||||
Scan ~/gt/plugins/ for plugin directories. Each plugin has a plugin.md with TOML frontmatter defining its gate (when to run) and instructions (what to do).
|
||||
|
||||
See docs/deacon-plugins.md for full documentation.
|
||||
|
||||
|
||||
@@ -1,35 +0,0 @@
|
||||
formula: rule-of-five
|
||||
type: expansion
|
||||
description: >
|
||||
Jeffrey Emanuel's discovery: LLM agents produce best work through 4-5
|
||||
iterative refinements. Breadth-first exploration, then editorial passes.
|
||||
version: 1
|
||||
template:
|
||||
- id: "{target}.draft"
|
||||
description: >
|
||||
Initial attempt at: {target.description}. Don't aim for perfection.
|
||||
Get the shape right. Breadth over depth.
|
||||
|
||||
- id: "{target}.refine-1"
|
||||
description: >
|
||||
First refinement pass. Focus: CORRECTNESS. Fix errors, bugs, mistakes.
|
||||
Is the logic sound?
|
||||
needs: ["{target}.draft"]
|
||||
|
||||
- id: "{target}.refine-2"
|
||||
description: >
|
||||
Second refinement pass. Focus: CLARITY. Can someone else understand
|
||||
this? Simplify. Remove jargon.
|
||||
needs: ["{target}.refine-1"]
|
||||
|
||||
- id: "{target}.refine-3"
|
||||
description: >
|
||||
Third refinement pass. Focus: EDGE CASES. What could go wrong?
|
||||
What's missing? Handle the unusual.
|
||||
needs: ["{target}.refine-2"]
|
||||
|
||||
- id: "{target}.refine-4"
|
||||
description: >
|
||||
Final polish. Focus: EXCELLENCE. This is the last pass. Make it shine.
|
||||
Is this something you'd be proud to ship?
|
||||
needs: ["{target}.refine-3"]
|
||||
@@ -1,31 +0,0 @@
|
||||
formula: security-audit
|
||||
type: aspect
|
||||
description: >
|
||||
Cross-cutting security concern. Applies security scanning before and
|
||||
after implementation steps.
|
||||
version: 1
|
||||
pointcuts:
|
||||
- glob: "*.implement"
|
||||
- glob: "*.submit"
|
||||
advice:
|
||||
around:
|
||||
before:
|
||||
- id: security-prescan
|
||||
description: >
|
||||
Pre-implementation security check. Review for secrets/credentials
|
||||
in scope. Check dependencies for known vulnerabilities.
|
||||
args:
|
||||
target: "{step.id}"
|
||||
after:
|
||||
- id: security-postscan
|
||||
description: >
|
||||
Post-implementation security scan. Scan new code for vulnerabilities
|
||||
(SAST). Check for hardcoded secrets. Review for OWASP Top 10 issues.
|
||||
args:
|
||||
target: "{step.id}"
|
||||
output:
|
||||
approved: boolean
|
||||
findings: list
|
||||
- gate:
|
||||
condition: "security-postscan.output.approved == true"
|
||||
message: Security approval required before proceeding
|
||||
@@ -1,45 +0,0 @@
|
||||
formula: shiny-enterprise
|
||||
extends: shiny
|
||||
description: >
|
||||
Enterprise-grade engineering workflow. Shiny + Rule of Five + Security +
|
||||
Performance Testing + Review Loop.
|
||||
version: 1
|
||||
compose:
|
||||
- expand:
|
||||
target: implement
|
||||
with: rule-of-five
|
||||
|
||||
- aspect:
|
||||
pointcut: "implement.*"
|
||||
with: security-audit
|
||||
|
||||
- gate:
|
||||
before: submit
|
||||
condition: "security-postscan.approved == true"
|
||||
message: Cannot submit without security approval
|
||||
|
||||
- branch:
|
||||
from: implement.refine-4
|
||||
steps:
|
||||
- id: perf-test
|
||||
description: Run performance benchmarks
|
||||
- id: load-test
|
||||
description: Run load/stress tests
|
||||
- id: chaos-test
|
||||
description: Run chaos engineering tests
|
||||
join: review
|
||||
|
||||
- loop:
|
||||
step: review
|
||||
until: "review.output.approved == true"
|
||||
max: 3
|
||||
on-max: escalate
|
||||
|
||||
- advice:
|
||||
target: "*"
|
||||
before:
|
||||
id: log-start
|
||||
description: "Log: Starting {step.id}"
|
||||
after:
|
||||
id: log-end
|
||||
description: "Log: Completed {step.id}"
|
||||
@@ -1,39 +0,0 @@
|
||||
formula: shiny
|
||||
description: >
|
||||
Engineer in a Box - the canonical right way. Design before you code.
|
||||
Review before you ship. Test before you submit.
|
||||
version: 1
|
||||
vars:
|
||||
feature: "{{feature}}"
|
||||
assignee: "{{assignee}}"
|
||||
steps:
|
||||
- id: design
|
||||
description: >
|
||||
Think carefully about architecture before writing code. Consider:
|
||||
How does this fit into the existing system? What are the edge cases?
|
||||
What could go wrong? Is there a simpler approach?
|
||||
|
||||
- id: implement
|
||||
description: >
|
||||
Write the code for {{feature}}. Follow the design. Keep it simple.
|
||||
Don't gold-plate.
|
||||
needs: [design]
|
||||
|
||||
- id: review
|
||||
description: >
|
||||
Review the implementation. Check for: Does it match the design?
|
||||
Are there obvious bugs? Is it readable and maintainable?
|
||||
Are there security concerns?
|
||||
needs: [implement]
|
||||
|
||||
- id: test
|
||||
description: >
|
||||
Write and run tests. Unit tests for new code, integration tests
|
||||
if needed, run the full test suite, fix any regressions.
|
||||
needs: [review]
|
||||
|
||||
- id: submit
|
||||
description: >
|
||||
Submit for merge. Final check: git status, git diff. Commit with
|
||||
clear message. Push and create PR.
|
||||
needs: [test]
|
||||
@@ -1,109 +0,0 @@
|
||||
# Towers of Hanoi Formula
|
||||
#
|
||||
# Demonstrates that molecule algebra solves the "million step workflow" problem.
|
||||
# LLMs fail on long sequences because errors accumulate (99.9%^1000 ≈ 37% success).
|
||||
# MAKER used voting to reduce error. We use mechanical structure instead.
|
||||
#
|
||||
# Key insight: The move sequence is deterministic. Only execution needs AI.
|
||||
# And each step is trivial: "move disk X from peg Y to peg Z".
|
||||
#
|
||||
# For n disks: 2^n - 1 moves
|
||||
# 20 disks = 1,048,575 moves (the "million step" problem)
|
||||
#
|
||||
# Currently hardcoded for 3 disks (7 moves) as proof of concept.
|
||||
# For million-step version, need to implement range expansion in cook.
|
||||
|
||||
formula: towers-of-hanoi
|
||||
version: 2
|
||||
description: |
|
||||
AGENT EXECUTION PROTOCOL - Towers of Hanoi
|
||||
|
||||
PURPOSE: This is a durability proof, not computation. Steps are pre-computed.
|
||||
Your job is to execute them mechanically, proving crash-recovery at scale.
|
||||
|
||||
EXECUTION LOOP:
|
||||
1. Find current state: bd mol current <mol-id>
|
||||
2. Find the next ready (unblocked) step
|
||||
3. Close it: bd close <step-id>
|
||||
4. Repeat until no ready steps remain
|
||||
|
||||
ON RESUME (after crash/restart/handoff):
|
||||
- Same as fresh start. The molecule IS the state.
|
||||
- Query `bd mol current <mol-id>`, continue from there.
|
||||
- No memory of previous session needed.
|
||||
|
||||
DO:
|
||||
- Close steps as fast as possible (they're trivial mechanical moves)
|
||||
- Use `gt handoff` when context fills (proactive cycling)
|
||||
- Trust the pre-computed solution - every move is already correct
|
||||
|
||||
DO NOT:
|
||||
- Try to solve Hanoi yourself - moves are already computed
|
||||
- Mark steps in_progress - just close them directly
|
||||
- Ask for permission - this is GUPP territory, just execute
|
||||
- Stop for human input - run autonomously until complete
|
||||
|
||||
MONITORING:
|
||||
- Progress: Count closed children of the molecule
|
||||
- For mega-molecules: Use convoy dashboard when available
|
||||
- Completion: All steps closed = molecule complete
|
||||
|
||||
This proves Gas Town can execute arbitrarily long workflows with
|
||||
nondeterministic idempotence - different sessions, same outcome.
|
||||
|
||||
vars:
|
||||
source_peg:
|
||||
default: "A"
|
||||
description: "Starting peg"
|
||||
target_peg:
|
||||
default: "C"
|
||||
description: "Target peg"
|
||||
auxiliary_peg:
|
||||
default: "B"
|
||||
description: "Helper peg"
|
||||
|
||||
# 3-disk solution: 7 moves (2^3 - 1)
|
||||
steps:
|
||||
- id: setup
|
||||
title: "Verify initial state"
|
||||
description: "All 3 disks stacked on peg A. Largest on bottom."
|
||||
|
||||
- id: move-1
|
||||
title: "Move disk 1: A → C"
|
||||
description: "Move the smallest disk from peg A to peg C."
|
||||
needs: [setup]
|
||||
|
||||
- id: move-2
|
||||
title: "Move disk 2: A → B"
|
||||
description: "Move disk 2 from peg A to peg B."
|
||||
needs: [move-1]
|
||||
|
||||
- id: move-3
|
||||
title: "Move disk 1: C → B"
|
||||
description: "Move disk 1 from peg C to peg B."
|
||||
needs: [move-2]
|
||||
|
||||
- id: move-4
|
||||
title: "Move disk 3: A → C"
|
||||
description: "Move the largest disk from peg A to peg C."
|
||||
needs: [move-3]
|
||||
|
||||
- id: move-5
|
||||
title: "Move disk 1: B → A"
|
||||
description: "Move disk 1 from peg B to peg A."
|
||||
needs: [move-4]
|
||||
|
||||
- id: move-6
|
||||
title: "Move disk 2: B → C"
|
||||
description: "Move disk 2 from peg B to peg C."
|
||||
needs: [move-5]
|
||||
|
||||
- id: move-7
|
||||
title: "Move disk 1: A → C"
|
||||
description: "Move disk 1 from peg A to peg C."
|
||||
needs: [move-6]
|
||||
|
||||
- id: verify
|
||||
title: "Verify final state"
|
||||
description: "All 3 disks now on peg C. Tower intact, all moves were legal."
|
||||
needs: [move-7]
|
||||
Reference in New Issue
Block a user