AHA — Any Help Available for HELL#

This page collects in-depth explanations of HELL’s architecture, structuring rules, and operational guidance. For a brief introduction, see the HELL landing page.

FLAMES Data Structure#

HELL organizes all content using the FLAMES structure:

Letter

Name

Code

Purpose

F

FeedbackFlow

ff

Whatever feedback has been received (from any source)

L

LifeLabLog

ll

Session logs, audit trails, append-only records

A

AnyAims

aa

Relevant aims, tasks, action items

M

MockupModels

mm

Early drafts, prototypes before promotion to HEAVEN

E

EnclosedEffort

ee

Enclosed materials, evidence, experimental data

S

Salt + System

—

Salt: Con-/Pro+ adversarial review crystals. System: architecture, design documents, structural rules.

Additionally:

  • Bug (bug/): Bug reports for theological reasoning errors (SINs and LIEs)

  • AAA (aaa/): AnyAllArrival — in-transit items not yet at their final location

Lettered-Numbering System#

All numbered sequences in HELL use the lettered-numbering system (see DD b11 for the full specification):

  • a1–a9: Reserved for greatest hits (assigned retroactively)

  • b10: Reserved for format template of the sequence

  • b11+: First usable entry; sequential assignment, never skip, never reuse

  • c100+, d1000+: Higher bands open as needed

Session Log (LL) Structuring Rules#

  1. All LLogs start in HELL (see CLAUDE.md LLog Rules).

  2. Logs are organized under ll/ by tool type: promy/, teles/, forge/, other/.

  3. Each log gets a lettered-number directory: ll/<tool>/b/<N>/.

  4. Non-typed logs (not tied to a specific compiler tool) go into ll/other/ with the next available number. If later a pattern emerges and a dedicated tool is created, new logs for that tool get their own subdirectory. The original other/ entries stay where they are.

  5. Log files follow the naming convention: <tool>_ll_<YYYYmMMdDD>_<descriptive-slug>.rst

Salt Crystallization Rules#

  1. Salt crystals group related Con/Pro pairs into coherent thematic clusters.

  2. Make crystals as large as possible while keeping them coherent.

  3. If material relates to more than one crystal, cross-reference it.

  4. The individual Con and Pro entries stay at their stable hell/con/b/<N>/ and hell/pro/b/<N>/ paths — crystals reference them, not move them.

  5. Each crystal’s toctree includes its Con/Pro entries for navigation.

MockupModel (MM) Rules#

  1. MockupModels live in HELL until promoted to HEAVEN.

  2. When promoted, the MM entry becomes a forwarding pointer (not deleted).

  3. HEAVEN stays clean — only finished work lives there.

File Safety Rules#

  1. NEVER delete content files. Move obsolete files to HH/ (HistoryHeap) for human review.

  2. Only the user deletes files.

  3. If a reorganization would break a link, leave a forwarding reference at the old location.