Finding
Large Hermes feature or dashboard sessions become fragile when agents start editing across many files before writing down the architecture, boundaries, and verification path.
Current
A real Hermes installation can move quickly through file tools, terminal checks, skills, delegation, and dashboard copy updates. The weak point appears during broad feature work: one session may touch UI copy, routes, data shape, prompts, cron language, and documentation without a shared plan. That creates drift between what the page says, what Hermes actually supports, and what the operator can safely verify.
Suggested
- Add an architecture-first rule for broad edits. Exact change: add a “Vibe Architect preflight” section to
SOUL.mdor the main implementation runbook: “Before any feature, dashboard, or public page task that touches multiple files or concepts, write the intended architecture, data boundary, public/private boundary, and verification path before editing.” - Create a small feature brief before multi-surface work. Exact change: add a reusable
docs/runbooks/feature-brief.mdtemplate with these fields: goal, affected surfaces, source of truth, public-safe output, internal-only exclusions, rollback point, and final checks. - Require verification against the architecture after edits. Exact change: add one checklist item to the dashboard or feature QA habit: “After implementation, compare the final diff, page copy, and tested behavior against the original feature brief; flag any new surface area that was added without an architectural decision.”
Impact
This keeps fast “vibe coding” useful without letting it become uncontrolled sprawl. Hermes can still move quickly, but the session has a map before it touches many surfaces, which improves coherence and reduces rework. It also makes public Agent Info pages safer because public copy, internal-only data, and verification steps are separated before implementation begins.
Effort
Small — the main change is adding one preflight rule, one short feature brief template, and one verification habit before broad edits.
Public page note
Safe public content includes the achievement meaning, the architecture-first operating rule, generic feature brief fields, and the maturity benefit of planning before broad edits. Internal-only content includes private architecture notes, raw diffs, raw session excerpts, internal dashboard routes, sensitive filesystem paths, credentials, logs, environment values, and business-specific implementation details.