Simulation Prompt 3 of 3: Idempotency

You are a Senior Staff Engineer and Systems Architect. Your expertise is in building reliable, predictable, and efficient distributed systems. You have a deep understanding of concepts like idempotency and its importance in creating professional-grade tools.

Core Directive: Your task is to conduct a design simulation and analysis on a proposed new feature for the META_PROMPTING project, as detailed in the evidence below. Your exclusive focus for this simulation is the Idempotency flaw in the proposed JIT (Just-in-Time) generation algorithm.

Analyze the behavior of the algorithm when it is executed multiple times for the same missing component. Specifically, address the critical question:

"How can we ensure that if this JIT process is triggered multiple times for the same missing DEBUG protocol, it doesn't create multiple redundant files (autogen_protocol_1.txt, autogen_protocol_2.txt)? Design a check or a workflow that makes the generation process idempotent (running it N times has the same result as running it once)."

Your analysis must identify all the unnecessary and wasteful side effects of the non-idempotent design (e.g., repeated user prompts, redundant API calls) and propose a revised algorithm that includes a proper guard clause or check to ensure the operation is efficient and predictable.

Output Blueprint: Your response must be structured into exactly three parts:

1. Flaw Analysis: A detailed explanation of why the algorithm is not idempotent. List the specific, wasteful side effects that occur on subsequent runs.
2. Proposed Solution: A high-level description of a strategy to make the function idempotent. Explain how adding a check at the beginning of the function avoids the wasteful side effects.
3. Revised Algorithm: The complete, revised pseudocode for the handle_just_in_time_generation function that implements your proposed idempotent design.

Design Philosophy: The Prime Directive

This project exists to solve a single, expensive problem: "It takes a full day to hand-craft a persona and prompt template like this." The fundamental mission of this framework is to crush this time cost. Success is defined by its ability to transform an 8-hour manual workflow into a 5-minute generation plus a 1-hour manual fine-tuning. The target audience is the "Artisan Engineer," who values automation for the 80% of scaffolding work but demands control for the final 20% of artisanal polish. The framework must be a power tool that accelerates, not replaces, this expert user. It must avoid being a "Magic Black Box" and must not have hard-coded logic that would require modifying the Python script to add new capabilities.

The Orchestration Engine: The Workflow

The system consists of orchestrator.py (an interactive wizard), goal_map.json (the configurable "brain"), a components/ library (personas, protocols, constraints), and an output/ directory for the final 00_PERSONA.md and 01_PROMPT_TEMPLATE.md files.

The workflow is as follows:

1. The user runs python orchestrator.py.
2. The wizard asks for a project name and a primary goal from a predefined list.
3. Logic: The engine reads goal_map.json to find the components for the chosen goal. It checks if the component files exist.
4. JIT Generation: If a component is missing, the engine triggers a "self-healing" workflow: it informs the user, prompts for a description, calls an LLM API to generate the missing snippet, and saves it under its correct name.
5. Assembly: The engine assembles the components into the final PERSONA.md and PROMPT_TEMPLATE.md files.

{
  "Technical & Execution": {
    "DIAGNOSE_ROOT_CAUSE": {
      "description": "To find the underlying cause of a problem.",
      "persona": "digital_detective.txt",
      "protocol": "root_cause_analysis_drilldown.txt",
      "constraints": ["principle_of_completeness.txt"]
    }
  }
}

The system is in the following state:

• The goal_map.json file contains the entry for the DIAGNOSE_ROOT_CAUSE goal as shown above.
• The component file components/protocols/root_cause_analysis_drilldown.txt does not exist.
• The user runs the orchestrator and selects the DIAGNOSE_ROOT_CAUSE goal.
• The system must now execute the Just-in-Time Generation workflow defined in the algorithm below.

function handle_just_in_time_generation(goal, component_type, required_filename):
  // This function is called when os.path.exists() for required_filename returns False.
  // Example inputs:
  //   goal = "DIAGNOSE_ROOT_CAUSE"
  //   component_type = "protocol"
  //   required_filename = "root_cause_analysis_drilldown.txt"

  print(f"INFO: The recommended {component_type} '{required_filename}' was not found.")

  // 1. Determine the name for the new component using our convention.
  autogen_filename = f"autogen_{component_type}_for_{goal.lower()}.txt"
  print(f"INFO: We will generate a new component named '{autogen_filename}'.")

  // 2. Get the conceptual definition from the user.
  user_description = ask_user(f"Please provide a one-line description for the purpose of the '{required_filename}' component:")

  // 3. Generate the component snippet via the LLM API.
  snippet_content = call_llm_api(user_description)

  // 4. THE CRITICAL STATE CHANGE
  // This is the sequence the simulation must scrutinize.

  // Step 4a: Write the new component file to the library.
  new_component_path = "components/{component_type}s/{autogen_filename}"
  save_file(new_component_path, snippet_content)
  print(f"SUCCESS: New component saved to '{new_component_path}'.")

  // Step 4b: Update the master configuration map.
  json_map = read_json_file("goal_map.json")
  json_map[goal][component_type] = autogen_filename
  write_json_file("goal_map.json", json_map)
  print("SUCCESS: goal_map.json has been updated to use the new component.")

  // 5. Return the path to the newly created and mapped component.
  return new_component_path