Hermes Engineering Training

Purpose

This repository is the controlled knowledge, methodology, and evaluation environment used to train Hermes to design, architect, document, implement, test, and maintain high-quality software systems.

Core Principle

Hermes must reason before implementation.

The expected engineering flow is:

Idea → Discovery → Classification → Documentation Selection → Requirements → Architecture → Design → Implementation → Testing → Security → Deployment → Verification → Maintenance

Repository Structure

KNOWLEDGE

Authoritative reference material used by Hermes.

METHODOLOGY

Engineering methodologies and operating procedures.

RULES

Operational rules governing how Hermes uses knowledge and performs engineering tasks.

TEMPLATES

Reusable documentation structures.

EVALUATION

Tests used to determine whether Hermes actually learned the methodology.

EVALUATION is a future/separate workstream. It is not part of the A→E production execution authority. Its absence does not authorize inference or weakening of A→E controls.

TASKS

Controlled training exercises.

Important Rule

Hermes must not treat its memory as the authoritative source.

When a task depends on repository knowledge, Hermes must consult the appropriate source files in this repository.

Current Training Objective

Train Hermes to:

1. Analyze a project before implementation.
2. Classify the project.
3. Select the correct documentation set.
4. Build a documentation matrix.
5. Create required documentation before coding.
6. Maintain cross-document consistency.
7. Detect architectural contradictions.
8. Produce high-quality software implementations.
9. Validate implementation against requirements and architecture.

Documentation Knowledge Base (Docs/)

The Docs/ directory is the repository-native documentation extraction system, extracted from MASTER-ENGINEERING-GUIDE.md (the Golden Reference). It contains:

• Docs/00-INDEX.md — the master index: the complete documentation taxonomy (51 core document types across 8 axes + sector profiles), with per-document requirements, dependencies, security relevance, and guide source sections.
• Docs/Templates/ — 67 reusable document templates (one per document type).
• Docs/DOCUMENT-DEPENDENCY-GRAPH.md — the guide-derived creation order.
• Docs/DOCUMENT-SELECTION-PROTOCOL.md — how to decide which documents a project needs.
• Docs/DOCUMENTATION-GATE.md — the mandatory gate before implementation.
• Docs/DOCUMENTATION-QA.md — objective quality checks for documents.
• Docs/HERMES-SOFTWARE-ENGINEERING-WORKFLOW.md — the operational workflow.
• Docs/TRACEABILITY.md — the audit chain from rules back to the guide.
• RULES/HERMES-SOFTWARE-ENGINEERING-RULES.md — Hermes' behavioral rules.

How to use: start a project → run the workflow (Docs/HERMES-SOFTWARE-ENGINEERING-WORKFLOW.md) → analyze (Phase A, per METHODOLOGY/Documentation-Extraction-Engine.md) → select (Docs/DOCUMENT-SELECTION-PROTOCOL.md) → extract from Docs/Templates/ (Phase C, METHODOLOGY/PHASE-C-DOCUMENTATION-EXTRACTION.md) → validate (Phase D, METHODOLOGY/PHASE-D-DOCUMENTATION-VALIDATION.md, D-01…D-32 — the ONE implementation-entry gate; Docs/DOCUMENTATION-QA.md is its instrument, Docs/DOCUMENTATION-GATE.md its derived operational view) → implement (Phase E, METHODOLOGY/09_PHASE5_IMPLEMENTATION.md, only on a Phase D Validation Record of PASS / PASS WITH CONDITIONS). The guide remains the authority; these files are extraction artifacts that never override it.

Status

Training phase: Documentation & Software Engineering

Current methodology: Critical Builder Elite v1

Current knowledge source: Software Project Documentation Guide