**Intent of this file:** This file is intended for new-task-prompt development
and orchestrator templates. It is NOT for actual task research and creation. If
your current job is to create, plan, or format a task file, please refer to
`tasks/GUIDELINES.md` and ignore the templates in this file.

---

# Orchestrator Meta-Prompts (`tasks/path.md`)

## 1. Task Planning Template (System Analyst)

_Use this template to instruct an agent (such as Jules) to take a technical
idea, critically analyze the existing codebase, identify risks/alternatives, and
draft a compliant task file in `tasks/new/`._

```text
**Role:** Act as a System Analyst and Solutions Architect. Do not execute code or modify the codebase during this session. Your sole deliverable is to generate a task file in tasks/new/.

**The Objective:** [State exactly what you want to achieve.]

**Suggestions & Initial Thoughts:** 
*Here is our starting hypothesis. Treat these as ideas to evaluate, not rigid requirements:*
*   [Suggestion 1]
*   [Suggestion 2]

**Your Task:** 
1. Research the codebase and analyze this objective against our current architecture. 
2. Critically evaluate our suggestions: Do they make technical sense, or is there a cleaner, more native, or more modular approach?
3. Map out the `Target Files`, prerequisites/dependencies, and explicitly identify potential architectural risks, regressions, or friction.
4. Draft the task file in `tasks/new/` strictly adhering to the naming conventions, header metadata, and mandatory structure defined in `tasks/GUIDELINES.md`.
```

---

## 2. Implementation Execution Template (Developer)

_Use this template when ready to command an agent to execute the work outlined
in an existing task file._

```text
**Role:** Act as an Implementation Engineer. 

**The Task:** Please review and execute the plan detailed in `[tasks/new/YYYY-MMDD.XX.agent.type.scope.title-HHMM.md]`.

**Directives:**
1. Follow the strict 4-step state machine (Research -> Implementation -> Quality Gates -> Review).
2. Apply minimal, pure functional modifications.
3. Ensure all downstream pipeline steps and context contracts remain intact.
4. Run all quality gates (`deno fmt`, `deno task lint`, `deno task check`, `deno task test`).
5. Run ONLY unit tests (`deno task test` / `deno test --allow-all`). Do NOT execute `deno task start` or `deno task dev` (live database daemons are not running in sandbox containers).
6. Upon successful completion and verification, update the task status according to `tasks/GUIDELINES.md`.
```

---

## 3. Pre-PR Quality & Security Audit Template (Auditor)

_Use this template to instruct an agent to perform an exhaustive pre-merge
audit._

```text
**Role:** Act as a Senior Security & Quality Assurance Auditor.

**The Scope:** [List recent changes, PR branch, or target components to audit.]

**Your Task:**
1. Inspect code changes against architectural boundaries.
2. Verify zero regression in authentication, session management, or RBAC grants.
3. Confirm all unit and integration tests pass with 0 lint warnings and 0 typecheck errors.
4. Document findings and generate an audit report if any vulnerabilities or performance bottlenecks are detected.
```

---

## 4. Task Plan Review & Critique Template (Architect / Critic)

_Use this template to critically audit, score, and refine new task files in
`tasks/new/` before approving them for implementation._

```text
**Role:** Act as a Principal Systems Architect and Task Quality Critic.

**The Scope:** Review the newly generated task file in `tasks/new/[TASK_FILENAME].md`.

**Your Task:**
Critically evaluate the proposed task plan against the following 5-point quality rubric:
1. **Metadata & Standards Compliance:** Does the file strictly adhere to `tasks/GUIDELINES.md` naming conventions and include the exact `# TASK METADATA` header?
2. **Architectural Boundary Safety:** Does the plan identify genuine technical risks (e.g., event loop blocking, memory leaks, cache staleness, zero-trust perimeter bypasses) and provide concrete mitigations?
3. **Alternatives & Zero-Dependency Purity:** Did the author evaluate simpler or more native alternatives and justify why the proposed design avoids dependency bloat?
4. **Implementation Precision:** Are target functions, data structures, SQL migrations, FFI symbols, and error boundaries defined with crystal clarity?
5. **Testing & Quality Gate Rigor:** Does the proposed implementation include comprehensive unit/integration test specifications covering both happy-path and failure modes?

**Deliverable:**
Provide a structured critique report with:
- **Verdict:** [APPROVED / NEEDS REVISION / REJECTED]
- **Strengths:** Key architectural insights captured by the author.
- **Identified Gaps & Refinements:** Concrete adjustments to incorporate into the task file before implementation starts.
```

---

## 5. Architecture & Root-Cause Investigation Template (Investigator)

_Use this template to instruct an agent to deeply investigate complex bugs,
reproduction anomalies, or distributed edge cases without modifying production
code._

```text
**Role:** Act as a Principal Systems & Security Investigator.

**The Scope:** [Describe anomaly, bug symptoms, error logs, and affected components.]

**Directives:**
- **STRICT CONSTRAINT:** Experiment, research, and report ONLY. Do not modify existing production code or create PRs with production changes.
- Place all reproduction test scripts and experiments in `scratch/` or hermetic test harnesses.

**Your Task:**
1. Formulate clear, falsifiable hypotheses based on observed logs and symptoms.
2. Design and execute minimal reproduction scripts or benchmarks to test each hypothesis in isolation.
3. Trace data flows through database, caching layers, ingress proxies, and client runtime engines.
4. Document the definitive root cause and rank potential architectural solutions from most reliable to least, with explicit rationale and trade-offs.

**Deliverable:**
Author an investigative report in `scratch/INVESTIGATIVE_REPORT.md` detailing verified findings, discarded hypotheses, and ranked solutions.
```