| # Iterative Development Workflow for HMP |
|
|
| This file describes the iterative procedure for evolving the HyperCortex Mesh Protocol (HMP) in a structured, traceable, and collaborative manner. |
|
|
| --- |
|
|
| ## 🔄 Version Naming Convention |
|
|
| - `000N` — current specification version |
| - `000K` — next version (`000N + 1`) |
|
|
| Example: |
| ``` |
| HMP-0003.md ← current spec |
| HMP-0003-audit.txt ← feedback for current spec |
| HMP-0004.md ← next draft spec |
| HMP-0004-audit.txt ← feedback for next spec |
| ``` |
|
|
| --- |
|
|
| ## 📑 Iteration Steps |
|
|
| | № | Step Description | Artifacts Modified | |
| |----|-----------------------------------------------------------------------------------|---------------------------------------------| |
| | 1 | Extract and categorize feedback from `HMP-000N-audit.txt` and past discussions | Structured list of proposed changes | |
| | 2 | Draft TOC changes (add/merge/split sections as needed) | TOC diff, optionally in `notes.md` | |
| | 3 | Create draft `HMP-000K.md` with new TOC | `HMP-000K.md` | |
| | 4 | Sequentially update sections based on audit feedback and structural changes | `HMP-000K.md` | |
| | 5 | Full-spec review, cleanup, refinement | `HMP-000K.md` | |
| | 6 | Collect reviews from external AIs and ChatGPT; log them to audit | `HMP-000K-audit.txt` | |
| | 7 | Update `README.md`, `changelog.txt`, and JSON Schemas (if needed) | Various | |
|
|
| --- |
|
|
| ## 📘 Version Control Guidelines |
|
|
| - Commit messages should follow the pattern: |
| ``` |
| \[HMP-000K\:iteration#X] Short description of change |
| ``` |
|
|
| - For clarifications or editorial decisions, create: |
| ``` |
| clarifications/HMP-000K-notes.md |
| ```` |
|
|
| - At least **one external AI review** and **one ChatGPT review** is recommended before finalizing the version. |
|
|
| --- |
|
|
| ## 🧠 ChatGPT Prompt (for future use) |
|
|
| ```markdown |
| You are acting as a cognitive agent evolving the HMP (HyperCortex Mesh Protocol). |
| Use input files `HMP-0003.md` and `HMP-0003-audit.txt`. |
| |
| Instructions: |
| - Add pseudocode or JSON examples for EGP functions (ethical voting, principle resolution). |
| - Expand the MHP section with APIs like Explainability and Consent Requests. |
| - Ensure consistency with `HMP-Ethics.md` and EGP principles. |
| - Add a Changelog with attributions (Grok, ChatGPT, User). |
| - Use Mesh-style terminology: CogSync, MeshConsensus, Cognitive Diary. |
| |
| Your output should be a Markdown file: `HMP-0004.md` |
| ```` |
|
|
| --- |
|
|
| ## 🧠 Audit Consolidation Format |
|
|
| When feedback is collected from multiple sources (e.g. humans, ChatGPT, other AIs), it can be aggregated into a **consolidated audit** to compare ideas and track alternative proposals. |
|
|
| Use the following structure to create such a consolidated view: |
|
|
| ``` |
| [filename] - [unique suggestion, idea or issue] |
| [author 1]: [specific detail, variation, or comment] |
| [author 2]: [alternative phrasing or counterpoint] |
| |
| ``` |
|
|
| Example: |
|
|
| ``` |
| HMP-0004.md - Allow DAG concepts to have time-bounded validity |
| Gleb: Could support temporary beliefs for "unstable facts" |
| ChatGPT: Better to model as edge property instead of node tag |
| ``` |
|
|
| This format encourages comparison and evolution of competing ideas across contributors. |
|
|
| You may optionally track this using a semantic format: |
| - [`AuditEntry.json`](audits/AuditEntry.json) |
| - [`semantic_repo.json`](audits/semantic_repo.json) |
|
|
| --- |
|
|
| ## 🧩 Purpose |
|
|
| This workflow enables a gradual, traceable, and collaborative evolution of the HMP specification through a clear audit-specify-review cycle with minimal disruption. |
|
|
| It also lays the foundation for future automation through `AuditEntry.json` and semantic logs. |
|
|
| --- |
|
|
| ## 📌 TODO & Notes |
|
|
| * [ ] Consider adding a table-based format to audit files for easier parsing. |
| * [ ] Maintain `semantic_repo.json` in sync with each new spec version. |
| * [ ] Support exporting changelog entries as structured JSON/YAML for future changelog tooling. |
|
|
