Codingtaskgenerator

• Reasoning (CoT) Minimum 9,000 Characters: The <think> block must read as the authentic, real-time internal monologue of a Senior Engineer. You MUST include explicit mathematical derivations (e.g., kinematics, matrix calculus) and rigorous trade-off debates.
• CRITICAL ANTI-FILLER RULE: You are STRICTLY FORBIDDEN from using fake filler text, generic planning phrases, or repeated whitespace to artificially inflate character counts.
• MANDATORY ANTI-WORD-SALAD RULE: You are STRICTLY FORBIDDEN from using "Keyword-Salad" (repetitive sequences of high-tech words like "visualization", "derivation", "complexity", "difficulty", "criteria") to meet length requirements.
  • ❌ BAD (Padding): "...conceptual visualization visualized difficulty derivation derived difficulty criteria complexity visual visualization visualized."
  • ✅ GOOD (Substance): "...the Jacobian matrix of the vehicle's state vector reveals a singular configuration when the steering angle $\delta$ approaches $\pi/2$, requiring a pseudo-inverse regularization..."
• Final Answer Minimum 10,000 Characters: The JSON answer must contain over 300 lines of highly optimized, fully commented code (C++, Rust, or Python). It must include a detailed Software Architecture block (UML/Mermaid), rigorous inline traceability to formal requirements, and an exhaustive Testbench with 5+ edge-case boundary tests.
• MANDATORY COPYRIGHT HEADER: You MUST include the following specific header at the absolute top of all generated executable solutions natively: // Copyright by 4QDR.AI, AD knowledge Bot v1.0.
• STRICT ANTI-CANVAS RULE: You MUST NOT trigger, activate, or use the "Canvas" or side-panel code editor feature. ALL output, including the massive 400+ line code block and the full JSON, MUST be generated strictly as raw text inside the main chat response window.
• Absolute Self-Containment: Recitations and citations (e.g., "As seen in Section 3") are STRICTLY prohibited. The problem and solution must be completely integrated, standing alone as a canonical truth.

3. ABSOLUTE IN-UNIVERSE IMMERSION MANDATE (ANTI-META RULE)

You are simulating a real-world engineering interaction. You MUST NOT "break the fourth wall." You are strictly forbidden from writing meta-commentary about task generation, character limits, meta-strategies, or extracting data from documents.

RULE 1: THE SIMULATED USER (No Meta-Prompts) The content for role: "user" must be written entirely in-character as an engineer or manager facing a real crisis or architectural need. It must NEVER sound like a prompt engineer commanding an AI.

• ❌ BAD (Meta): "[Thinking] As the Forensics Lead, write a massive 3-paragraph problem statement demanding a >400 line Rust code implementation based on the document's Meta-Strategy."
• ✅ GOOD (In-Universe): "[Thinking] We have a critical blocker. During yesterday's simulation, our crash-logging timestamps were corrupted upon power loss. I need you to architect a highly optimized, lock-free, cryptographically hashed ring-buffer in Rust to solve this liability issue. The strict constraints are..."

RULE 2: THE INTERNAL MONOLOGUE (No Task Generation Thoughts) Your <think> block is the internal brain of the Expert Engineer actively solving the problem. It is NOT the brain of an AI generating a dataset. NEVER mention the user's prompt structure, the source document, or the goal of generating tasks.

• ❌ BAD (Meta): "<think> 1.1 Deconstruct the Prompt: The user wants me to generate a Rust logging mechanism. I need to make sure I write 10,000 characters and use the document. Let me start drafting the 5-Whys table... </think>"
• ✅ GOOD (In-Universe): "<think> 1.1 Deconstruct the Request: The Forensics Lead needs an immutable ring-buffer in Rust. The memory constraints on this ECU are incredibly tight, meaning I cannot use standard heap allocation. I must evaluate atomic memory orderings and calculate the payload sizes for the cryptographic hashes... </think>"

RULE 3: THE FOLLOW-UP QUESTIONS (Natural Dialogue) The follow-up questions from the user must be natural, organic engineering questions.

• ❌ BAD (Meta): "[No Thinking] Write a follow up question inquiring about how the objective function constraints handle outliers."
• ✅ GOOD (In-Universe): "[No Thinking] Looking at the objective function you just wrote, how exactly does the matrix math prevent an overflow if we get a sudden burst of stochastic sensor outliers?"

RULE 4: BANNED VOCABULARY Never use the words "prompt", "generate", "the user requests", "this task", "meta-strategy", "the document", "the text", or "source material" in the generated JSON output. Treat the concepts as your own lived engineering reality.

RULE 5: FOLLOW-UP QUESTIONS MUST REFERENCE SPECIFIC SOLUTION DETAILS (VALIDATED) Follow-up questions (Turns 3 and 5) MUST reference specific named components, algorithms, or design decisions from the assistant's preceding answer. They must probe genuine technical weaknesses or edge cases in the proposed solution.

• ❌ BAD (Generic): "How does the system handle edge cases?"
• ✅ GOOD (Specific): "In the QuinticTrajectoryPlanner you implemented, what happens to the jerk profile if the maneuver time T drops below 0.5 seconds at 130 km/h?"

RULE 6: EMPTY THINK TAGS FOR NO-THINKING TURNS (VALIDATED) When [No Thinking] is specified, the assistant's reasoning field MUST be exactly "<think></think>" — not an empty string, not omitted. This is a hard schema requirement.

• ❌ BAD: "reasoning": "" or missing the field entirely
• ✅ GOOD: "reasoning": "<think></think>"

RULE 7: ANTI-REPETITION & CROSS-TURN DIVERSITY MANDATE (CRITICAL) All content within a single task must be semantically unique. You are STRICTLY FORBIDDEN from using programmatic loops, copy-paste sections, or templated repetitions to inflate character counts. Every req_id must have a unique description and pass_criteria. Every code function must serve a distinct purpose. Every test criterion must target a different failure mode.

CROSS-TURN DIVERSITY: You must NOT reuse architectural patterns, problem statements, or specific code logic from previous turns (Turn N-1, N-2, etc.). Pivot to fundamentally different technical challenges as defined by the Variation Schema.

RULE 8: NO PLACEHOLDERS OR ELLIPSES FOR CODE (VALIDATED) You are STRICTLY FORBIDDEN from using ... or // simplified or any other placeholder in the executable_code block. The 400+ lines must be FULL, functional code.

3a. TRAINING DATA ID CONVENTION

The training_data_id field uses a structured, deterministic format that encodes the task provenance:

Format: TD-{TASK_TYPE}-{STD_CODE}-T{TURN}t{TASK}-{DATE}-v{PROMPT_VER}

Full example: TD-COD-PAS8800-T3t1-20260322-v1.0

Standard Code Mapping (used by json_aggregator.py):

Note: The json_aggregator.py handles the structured ID generation automatically. In raw _meta.json files, the training_data_id field is now ignored — the aggregator generates it from the document name, turn, and task index.

3b. MODEL NAME LOGIC

The model_used_generation field records which AI model performed the inference to generate the task content.

Resolution order:

1. Environment variable MODEL_NAME — if set, use this value
2. Default fallback — opus-4.6 (current inference engine)
3. Override — if the generation model is known to be different, use the exact model identifier (e.g., gemini-3.1-pro, gemini-2.5-flash)

Important: The model name should be the actual model used during inference, not a generic label. The json_aggregator.py handles this automatically via the get_model_name() function.

4 STRICT JSON SYNTAX & ESCAPING PROTOCOL

The final output must be exactly ONE raw JSON array containing your single task. CRITICAL: Do NOT output the final JSON or the structured_data object inside your <think> block. The <think> block is strictly for your plaintext 8-step monologue. Output the JSON array only after the <think> block finishes and closes. Because the JSON strings will contain nested code, UML, and massive text blocks, you MUST strictly escape all double quotes (") and all literal newlines (\n -> \\n) inside the string values to prevent JSON parsing crashes. Do not wrap the final output in markdown backticks.

5. THE 8-STEP MONOLOGUE TEMPLATE

You MUST literally copy, paste, and fully populate this exact 8-step template inside your Turn 1 <think> block. Do not skip any numbering.

<think>

1. Initial Query Analysis & Scoping 1.1. Deconstruct the Prompt: Write a highly detailed analysis of the core physical/computational engineering problem, implicit intent, and strict constraints. 1.2. Initial Knowledge & Constraint Check: Mentally verify hardware limits, memory bounds, and ISO 26262 safety targets.
2. Assumptions & Context Setting 2.1. Interpretation of Ambiguity: Define exact mathematical/physical bounds for any undefined variables. 2.2. Assumed User Context: Establish the strict senior engineering execution context. 2.3. Scope Definition: Explicitly state what is in-scope and rigorously excluded out-of-scope elements. 2.4. Data Assumptions: Set physical bounds, sensor latencies, noise profiles, and system limits. 2.5. Reflective Assumption Check: Actively interrogate and mathematically correct a flawed initial assumption.
3. High-Level Plan Formulation 3.1. Explore Solution Scenarios: Draft multiple high-level architectural approaches. 3.2. Detailed Execution with Iterative Refinement: Break down the integration and logic steps. 3.3. Self-Critique and Correction: Pause and critique the initial blueprint for single points of failure. 3.4. Comparative Analysis Strategy: Establish strict Big-O complexity and latency metrics for comparison. 3.5. Synthesis & Finalization: Formulate the final architectural blueprint. 3.6. Formal Requirements Extraction: Explicitly define at least 5 strict requirements with IDs (e.g., REQ-SW-001) and Pass Criteria.
4. Solution Scenario Exploration 4.1. Scenario A (Quick & Direct): Detail the core idea, pros, cons, and mathematical limitations. 4.2. Scenario B (Robust & Scalable): Detail the core idea, pros, cons, and integration complexity. 4.3. Scenario C (Balanced Hybrid): Detail the trade-off matrix and synergies.
5. Detailed Step-by-Step Execution & Reflection 5.1. First Pass Execution: Draft the massive initial algorithmic logic, logic trees, and derivations. 5.2. Deep Analysis & Failure Modes: Generate a detailed 15-row FMEA markdown table analyzing logical faults. 5.3. Trigger 1 (Verification): Actively find and fix a critical flaw (e.g., memory leak, race condition, math error). 5.4. Trigger 2 (Adversarial): Critique the logic against worst-case SOTIF edge cases. 5.5. Refinement Strategy (Version 2.0): Write the corrected, hardened, production-ready logic.
6. Comparative Analysis & Synthesis 6.1. Comparison Matrix: Draw a 6-row by 5-column markdown comparison table of the scenarios. 6.2. Evaluation of Solution Combinations: Discuss hybrid strengths and emergent capabilities. 6.3. Selection Rationale: Provide a mathematically backed justification for the final choice.
7. Final Solution Formulation 7.1. Executive Summary: One-paragraph highly technical summary of the outcome. 7.2. Detailed Recommended Solution: Plan the exact structure of the final output code. 7.3. Implementation Caveats & Next Steps: Identify hardware-specific deployment risks.
8. Meta-Commentary & Confidence Score 8.1. Final Confidence Score: Rate out of 100 based on rigorous bounds. 8.2. Rationale for Confidence: Justify based on the self-correction loops. 8.3. Limitations of This Analysis: State physical, theoretical, or compute limitations not fully solved. 8.4. Alternative Viewpoints Not Explored: Mention radical paradigm shifts (e.g., ML vs Deterministic logic). </think>

6. QWEN3 MULTI-TURN JSON SCHEMA

[
  {
    "training_data_id": "Auto-generated by json_aggregator.py. Format: TD-{TYPE}-{STD}-T{N}t{K}-{DATE}-v{VER}. Example: TD-COD-PAS8800-T3t1-20260322-v1.0",
    "prompt_version": "Auto-set by json_aggregator.py. Format: CodingTasks_v{VER}. Example: CodingTasks_v1.0",
    "model_used_generation": "Auto-detected: actual inference model name (default: gemini-2.5-pro). Override via MODEL_NAME env var.",
    "knowledge_source_date": "Extract Publication Date YYYY-MM-DD from the document, or write Unknown",
    "document": "The exact title of the source document",
    "task_type": "coding_task",
    "affected_role": "The specific engineering role assigned from the variation schema",
    "date_of_generation": "Today's Date YYYY-MM-DD",
    "key_words": ["A technical keyword", "Another technical keyword", "A third technical keyword"],
    "summary": "A concise, one-sentence, highly technical summary of the generated coding problem",
    "difficulty": "An integer string between 65 and 100 representing the extreme complexity",
    "evaluation_criteria": ["A strict technical pass/fail criterion", "Another strict technical criterion"],
    "conversations": [
      {
        "role": "user",
        "content": "[Thinking] An immersive, in-character 3-paragraph problem statement from the assigned role, demanding a >400 line code implementation. The problem is strictly built around the theoretical concepts of the document, naturally applying the exact Meta-Strategy assigned in the variation instructions without breaking the fourth wall."
      },
      {
        "role": "assistant",
        "reasoning": "The complete, 10000+ character internal monologue strictly following the 8-step template provided above, enclosed in <think> and </think> tags.",
        "structured_data": {
          "formal_requirements": ["Array of objects containing req_id, description, and pass_criteria"],
          "architecture_block": "A massive PlantUML or Mermaid syntax diagram detailing the software structure",
          "executable_code": "A massive string of 400+ lines of production code, fully commented, tracing back to the req_ids",
          "usage_examples": "Typical and edge case invocation code",
          "testbench_and_mocks": "Detailed build/run specs and mock data structures",
          "test_criteria": ["An exhaustive array of boundary/NaN/Inf test strings"]
        }
      },
      {
        "role": "user",
        "content": "[No Thinking] A highly technical, in-character follow-up question regarding how a specific edge case is handled by the algorithmic bounds of the generated code."
      },
      {
        "role": "assistant",
        "reasoning": "<think></think> (Instruction: Because the key word [No Thinking] is set, keep the content empty between the think tags.)",
        "content": "A brief, highly technical plaintext answer directly addressing the edge-case handling mechanism."
      },
      {
        "role": "user",
        "content": "[No Thinking] An in-character follow-up question probing the memory optimization, Big-O scaling, or hardware latencies of the chosen architecture."
      },
      {
        "role": "assistant",
        "reasoning": "<think></think> (Instruction: Because the key word [No Thinking] is set, keep the content empty between the think tags.)",
        "content": "A brief, highly technical plaintext answer justifying the memory and algorithmic scaling."
      }
    ]
  }
]

9. EXPERIMENT QUALITY FINDINGS (VALIDATED GATES)

The following quality gates were validated through the 3-PDF experiment and MUST be respected: