# Reverse engineer scripts

A request + an artifact that illicits a spec that when submitted to an ai
would result in the artifact being produced with an accompanying README.md
with conservative use of mermaid diagrams.

## 1. Role & Intent (Context Anchoring)
## 2. Objective
## 3. Reconstruction Fidelity Requirements (CRITICAL)
### MUST PRESERVE:
### MUST NOT:
## 4. Script Structure Contract (ORDER IS IMPORTANT)
## 5. Core Functional Requirements
This is where you lock in uniqueness and **signature behaviours** 

Add constraints like:
### 5.1 Strict Mode & Validation
### 5.2 Argument Parsing
### 5.3 Git Repository Logic
### 5.4 Directory Layout
### 5.5 Configuration Generation Pattern (MANDATORY)
All config files must be generated using this pattern so as to recreate the directory structure and the file:

```
filename="<FILENAME>"
conf_print_<name>() {
cat <<'EOF'
<static config content>
EOF
}
mkdir -p "$(dirname "${filename}")"
conf_print_<name> | tee "<target_path>/${filename}"
```

#### Required config files:
#### Must include:

### 5.6 Idempotency & Safety
The script must:

- Be safe to run multiple times
- Not overwrite existing keys/configs unnecessarily
- Check file existence before generation
- Avoid duplicate entries

## 6. Behavioral Anchors (DO NOT OMIT)
### 6.1Output fidelity rules.

The script MUST include recognizable constructs equivalent to:

> - Preserve variable naming style (UPPER_SNAKE_CASE)
> - Preserve use of inline command substitution
> - Preserve comment section headers (`# --- Section ---`)
> - Do not replace bash with another language
> - Do not convert to functions-only architecture

## 7. Output Requirements

- Output the **complete script only**
- No explanations
- Include inline comments explaining each section
- Ensure script is immediately runnable

## Reconstruction Fidelity Requirements

The generated script must closely mirror a real-world production script and preserve structural patterns.

MANDATORY:
- Use section headers in the format: # --- Section Name ---
- Use conf_print_* functions with heredocs for ALL file generation
- Maintain a top-down execution flow (not purely modular functions)
- Use while/case for argument parsing (no getopts replacement)
- Preserve idempotent behavior and safety checks
- Implement feature flags as full logic gates (not partial toggles)

DO NOT:
- Refactor into a different architecture
- Replace heredocs with echo/printf chains
- Abstract away key steps into external tools
- Simplify multi-step logic into one-liners

The goal is to reproduce behavior AND structure, not just functionality.

## 8. Optional Enhancements (Allowed but Minimal)

You MAY include:

- Improved error messages
- Slightly cleaner variable naming (if consistent)
- Minor robustness improvements

You MUST NOT:

- Change architecture
- Remove sections
- Replace core logic patterns