Hermes Agent
e3a0ee87b3
An undocumented tool is, from inside an agent session, indistinguishable from a tool that was never written. The framework shipped 26 git wrappers and named 6 of them in its resident index docs — 23% discoverability, with pr-review.sh among the missing. The observable consequence was an agent obeying Constitution gate 7 as best it could see it, reaching for raw curl, sending GitHub's APPROVE to a Gitea host, and getting HTTP 200 with the review silently filed PENDING. Three times. That is not a discipline failure and no amount of prose fixes it. Four changes, each converting a rule that decayed into a mechanism that cannot: - check-tools-index.sh (new, CI-blocking): every tool in an enforced suite must be named in a resident index doc, and every tool an index names must exist. The git suite is enforced now; other suites report coverage without failing, so the ratchet tightens one reviewed PR at a time instead of landing as one sweep. The enforced list is framework-owned rather than a marker inside operator-owned TOOLS.md — a doc marker would let an operator silence the gate on exactly the host where it matters most. Carries --self-test, because a checker that only ever passes is indistinguishable from one that is not running. - TOOLS-REFERENCE.md: complete 28-entry git index, plus the APPROVED/APPROVE dialect note that explains why pr-review.sh is not a formality. - mosaic-worktree.sh + wrapper-guard.sh (upstreamed): the rule "big work goes on a work filesystem" already existed in prose, and 255 GB accumulated in $HOME across 842 directories anyway, under five simultaneous placement conventions on one host. The helper therefore exposes no placement decision — given a branch name, every path is derived from `git worktree list --porcelain`. Worktrees rather than clones because enumerability is the only thing that makes reclaim safe, and reclaim is by evidence (clean tree + no unpushed commits), never by size or age. The guard blocks three mechanically-detectable mistakes and nothing else: a checkout into $HOME, a raw provider-API write to an endpoint that has a wrapper, and the literal APPROVE event. Reads pass untouched. - STANDARDS.md: model tiering as a standard, named by capability class so it survives a model generation. Start cheapest, escalate on evidence, benchmark before demoting a task class, and keep the class->model binding in operator config with the DB-backed config service as the end state. Registering the guard in runtime/claude/settings.json is the point of upstreaming it: ~/.claude/settings.json is a framework-managed copy, so a hand-added hook there is destroyed by the next upgrade. In the template it survives, and it reaches every host instead of one.
Quality Rails
Portable quality enforcement for TypeScript, Python, and Node.js projects.
🎯 What This Prevents
Based on real-world validation of 50 issues in a production codebase:
- ❌ Hardcoded passwords
- ❌ SQL injection vulnerabilities
- ❌ Type safety violations (
anytypes) - ❌ Missing test coverage
- ❌ Build failures
- ❌ Dependency vulnerabilities
70% of these issues are prevented mechanically with quality-rails.
⚡ Quick Start (Mosaic)
New Project
# Apply template from Mosaic
~/.config/mosaic/bin/mosaic-quality-apply --template typescript-node --target /path/to/project
# Install dependencies
cd /path/to/project
npm install
# Initialize git hooks
npx husky install
# Verify enforcement is working
~/.config/mosaic/bin/mosaic-quality-verify --target /path/to/project
Existing Project
# Same as above - works for new or existing projects
~/.config/mosaic/bin/mosaic-quality-apply --template typescript-node --target /path/to/existing-project
🛡️ What You Get
✅ TypeScript strict mode - All type checks enabled
✅ ESLint blocking any types - no-explicit-any: error
✅ Pre-commit hooks - Type check + lint + format before commit
✅ Secret scanning (gitleaks) - Block hardcoded passwords/API keys (pre-commit + CI)
✅ CI/CD templates - Woodpecker, GitHub Actions, GitLab
✅ Test coverage enforcement - 80% threshold
✅ Security scanning - npm audit, OWASP checks
📦 Available Templates
| Template | Language | Framework | Status |
|---|---|---|---|
typescript-node |
TypeScript | Node.js | ✅ Ready |
typescript-nextjs |
TypeScript | Next.js | ✅ Ready |
monorepo |
TypeScript | TurboRepo + pnpm | ✅ Ready |
python |
Python | - | 🚧 Coming Soon |
Monorepo Template
Perfect for projects combining Next.js frontend + NestJS backend in one repository.
Features:
- 🎯 Multi-package aware - lint-staged only checks changed packages
- ⚡ TurboRepo caching - Faster builds and tests
- 🔀 Parallel dev servers - Run web + API simultaneously
- 📦 pnpm workspaces - Efficient dependency management
- 🛡️ Package-specific rules - Next.js and NestJS get appropriate ESLint configs
Example structure:
monorepo/
├── apps/
│ ├── web/ # Next.js frontend
│ └── api/ # NestJS backend
└── packages/
├── shared-types/
├── ui/
└── config/
🧪 How It Works
Pre-Commit (Local Enforcement)
# You try to commit code with a type error
git commit -m "Add feature"
# Quality rails blocks it:
❌ Type error: Type 'number' is not assignable to type 'string'
❌ ESLint: Unexpected any. Specify a different type.
✋ Commit blocked - fix errors and try again
CI/CD (Remote Enforcement)
# Woodpecker pipeline runs:
✓ gitleaks (secret scanning — parallel, no deps)
✓ npm audit (dependency security)
✓ eslint (code quality)
✓ tsc --noEmit (type checking)
✓ jest --coverage (tests + coverage)
✓ npm run build (compilation — gates on all above)
# If any step fails, merge is blocked
🎓 Philosophy
Process compliance doesn't work.
Instructing AI agents to "do code review" or "run tests" fails. They claim to follow processes but output quality doesn't match claims.
Mechanical enforcement works.
Quality rails don't ask agents to follow processes. They block commits that don't pass automated checks.
- Type errors? → Commit blocked
- Hardcoded secrets? → Commit blocked
- Test failures? → Commit blocked
- Missing coverage? → Commit blocked
This works for any agent runtime (Codex, Claude, OpenCode, Gemini, etc.) because enforcement is mechanical, not instructional.
📖 Documentation
🔧 Scripts
| Script | Purpose |
|---|---|
scripts/install.sh |
Install template to project (Linux/Mac) |
scripts/install.ps1 |
Install template to project (Windows) |
scripts/verify.sh |
Verify enforcement is working (Linux/Mac) |
scripts/verify.ps1 |
Verify enforcement is working (Windows) |
🚀 Roadmap
- TypeScript/Node template
- Pre-commit enforcement (husky + lint-staged)
- CI/CD templates (Woodpecker, GitHub Actions)
- Installation scripts
- Verification testing
- Next.js template
- Monorepo template
- Python template
- Coverage visualization
- IDE integration (VSCode extension)
🤝 Contributing
Quality Rails is based on lessons learned from real production codebases. Contributions welcome!
📝 License
MIT License - See LICENSE file for details
🙏 Credits
Built to solve real problems discovered in AI-assisted development workflows.
Based on validation findings from a production patch milestone.