/**
 * Canonical inline-workflow definitions for the four built-in workflow IDs:
 * `general`, `feature`, `bug-fix`, `quick-fix`.
 *
 * Used by the project.yaml migration (`migrate-project-yaml.ts`) to seed
 * workflows for legacy projects that previously relied on the now-deleted
 * `defaults/workflows/*.yaml` builtin fallbacks (Follow-up A).
 *
 * Structural step refs use `{ component, command }` — the component name is
 * caller-supplied (defaults to the project name per the multi-repo migration
 * convention; see docs/design/multi-repo-components.md §1.3).
 *
 * Mirrors the canonical shape produced by `scripts/migrate-dev-project-workflows.mjs`
 * (which is now obsolete now that `defaults/workflows/*.yaml` is gone).
 */
export interface SeededVerifyStep {
    name: string;
    type: "command" | "llm-review" | "agent-qa";
    component?: string;
    command?: string;
    run?: string;
    role?: string;
    prompt?: string;
    phase?: number;
    timeout?: number;
    expect?: "success" | "failure";
    optional?: boolean;
    label?: string;
    description?: string;
    [key: string]: unknown;
}
export interface SeededGate {
    id: string;
    name: string;
    description?: string;
    depends_on?: string[];
    content?: boolean;
    inject_downstream?: boolean;
    metadata?: Record<string, string>;
    verify?: SeededVerifyStep[];
}
export interface SeededWorkflow {
    id: string;
    name: string;
    description?: string;
    gates: SeededGate[];
}
/** Ralph-loop description applied to canonical implementation gates. */
export declare const RALPH_LOOP_DESCRIPTION = "Ralph loop: implement the design, then run the verification suite. Failures circle the agent back to fix-and-retry until the gate passes.";
/** Standard "Ready to Merge" verification gate — identical across all four flows. */
export declare function readyToMergeGate(): SeededGate;
export declare const DOC_PROMPT = "Review documentation for the changes on branch {{branch}} vs origin/{{baseBranch}}.\n\nRun `git diff origin/{{baseBranch}}...{{branch}} -- . ':!package-lock.json'` to see all changes.\nRead the key documentation files: AGENTS.md, README.md, and files in docs/.\n\nThe goal spec is:\n{{goal_spec}}\n\n**Documentation location rules:**\n- Detailed feature behavior, architecture explanations, workflows, and durable reference material should usually live in `docs/*.md`.\n- `README.md` should cover entrypoints, setup, and concise high-level project orientation.\n- `AGENTS.md` should only change when agent-operational guidance changed: repo navigation, architecture launchpad notes, common task recipes, debugging index entries, verification flow, or other instructions an agent needs in many sessions.\n- Do NOT require an `AGENTS.md` update for routine product or feature documentation when `docs/` or `README.md` is the better home.\n\n**Check 1 \u2014 Every feature is documented:**\n- Every new user-facing feature, API endpoint, config option, or behavioral change introduced in this branch must be documented somewhere.\n- If a feature is only described in code comments, that is NOT sufficient \u2014 it must appear in a .md file.\n- List any undocumented features.\n- Also flag documentation placed in the wrong home when that placement creates pressure to grow `AGENTS.md` unnecessarily.\n\n**Check 2 \u2014 Existing documentation is updated:**\n- If the changes modify behavior that is already documented, the documentation must be updated to reflect the new behavior.\n- Check for stale references: old API signatures, removed config options, renamed files, changed defaults, altered workflows.\n- List any stale documentation that was not updated.\n\n**Check 3 \u2014 Documentation placement is appropriate:**\n- Prefer `docs/` for detailed explanations.\n- Prefer `README.md` for top-level orientation.\n- Only require `AGENTS.md` changes for agent-facing operational guidance.\n- Flag branches that add routine feature detail to `AGENTS.md` instead of the better destination.\n\n**Check 4 \u2014 AGENTS.md edit discipline (only if this branch modifies AGENTS.md):**\nAGENTS.md is loaded into every agent turn \u2014 its size is a direct per-turn token cost on every session. FAIL this check if the diff:\n- Adds a Recipe or Debugging entry that spans more than one line. Multi-sentence prose, inlined schemas, code blocks, and step-by-step walkthroughs all belong in `docs/`, not AGENTS.md.\n- Adds a new entry where extending or replacing an existing entry on the same topic would have worked (net adds drive bloat).\n- Adds both a Recipe and a Debugging entry for the same fix (pick one).\n- Adds a categorical subsection past ~12 entries without splitting it.\nIf the diff fixes any of the above (e.g. it shortens long entries, dedupes recipe\u2194debug pairs, splits a large subsection), say so and PASS.\n\nSummarize with PASS/FAIL for each check and specific items to address.";
export declare const DESIGN_REVIEW_PROMPT = "Review this design document for structure, clarity, and completeness. Verify:\n1. Approach is clearly described with rationale\n2. File changes are listed with specific descriptions\n3. Acceptance criteria are specific and testable\n4. Edge cases and error handling are considered\n5. **E2E test plan** \u2014 the design MUST include a section describing browser-based E2E tests that validate the user journey end-to-end. If no E2E test plan section is present, FAIL this review.";
export declare const GAP_ANALYSIS_DESIGN_PROMPT = "Compare the goal specification to this design document.\n\nThe goal spec is:\n{{goal_spec}}\n\nIdentify:\n1. Requirements in the goal spec not addressed in the design\n2. Acceptance criteria not covered by the proposed changes\n3. Edge cases mentioned in the goal but missing from the design\n4. Any contradictions between the goal and the design\n\nUse your tools to read the design document content from the signal.";
export declare const GAP_ANALYSIS_IMPL_PROMPT = "Compare the goal specification and design document to the actual implementation on this branch.\n\nThe goal spec is:\n{{goal_spec}}\n\nRun `git diff origin/{{baseBranch}}...{{branch}} -- . ':!package-lock.json'` to see the implementation diff.\nRead the design document content from upstream gates.\n\nIdentify:\n1. Features described in the goal/design but not implemented\n2. Acceptance criteria not met by the code changes\n3. Implemented behavior that contradicts the specification\n\nIMPORTANT: Ignore documentation gaps. This gap analysis runs during the implementation phase, BEFORE the documentation gate. Do NOT flag missing or outdated documentation, README updates, design-doc updates, code comments, or other docs-only artifacts as gaps \u2014 those are addressed by the dedicated documentation gate later in the workflow. Focus exclusively on code/behavior gaps relative to the spec and design.";
export declare const CODE_REVIEW_PROMPT = "Review the code changes on branch {{branch}} vs origin/{{baseBranch}} for quality.\n\nStart with `git diff --stat origin/{{baseBranch}}...{{branch}} -- . ':!package-lock.json'` to see which files changed.\nThen use `git diff origin/{{baseBranch}}...{{branch}} -M -- . ':!package-lock.json'` (with rename detection) to see actual content changes.\nFor large diffs, review files individually with `read` rather than dumping the entire diff into context.\n\nCheck:\n1. Correctness \u2014 logic errors, off-by-one, race conditions\n2. Error handling \u2014 missing try/catch, unhandled promise rejections\n3. Edge cases \u2014 null/undefined, empty arrays, boundary values\n4. Code style \u2014 consistent naming, no dead code, clear intent\n5. Test coverage \u2014 are new behaviors tested?";
export declare const SECURITY_REVIEW_PROMPT = "Security review of changes on branch {{branch}} vs origin/{{baseBranch}}.\n\nRun `git diff origin/{{baseBranch}}...{{branch}} -- . ':!package-lock.json'` to see changes.\n\nCheck:\n1. Injection risks \u2014 command injection, path traversal, template injection\n2. Auth/authz \u2014 are new endpoints properly authenticated?\n3. Data validation \u2014 are inputs validated and sanitized?\n4. Secrets handling \u2014 no hardcoded secrets, tokens, or credentials\n5. Dependency risks \u2014 any new dependencies with known vulnerabilities?";
/** Build the four canonical workflows targeting `componentName` (typically the project name). */
export declare function buildDefaultWorkflows(componentName: string): Record<string, SeededWorkflow>;
//# sourceMappingURL=seed-default-workflows.d.ts.map