/*
 * Copyright 2026, Jaime Terrats.
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *     http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */
import { workflow } from '../workflow-generator.js';
export function generateSaWorkflows(version) {
    return {
        'input-analysis.md': workflow(version, 'Input Analysis — Raw inputs to Feature', `
## 1. Gather Input

Ask: "Please paste the inputs — as a table (Excel/CSV/Markdown) or a description, or both."

## 2. Identify Input Type

- **Tabular**: Excel paste, CSV, TSV, Markdown table. Map columns to Feature fields.
- **Free-form**: prose describing what the user/business wants. Synthesize into feature.
- **Mixed**: description + table — description provides strategic context, table provides ACs.

## 3. Map Columns (for tabular inputs)

| Common column (case-insensitive) | Maps to |
|---|---|
| Requirement / Description / User Need | AC source |
| ID / Req ID / Story ID | AC reference |
| Persona / Role / Actor | Applicable Personas |
| Priority / MoSCoW | Note alongside AC |
| Stakeholder / Owner / Requested By | Business Stakeholders |
| System / Source / Target / Dependency | Dependencies |
| KPI / Metric / Success Measure | KPIs |
| Notes / Comments | Supporting context |

## 4. Extract Feature

Derive each field:
- Feature Summary (2-3 sentences — the capability, not the table structure)
- Value Proposition / Objective (or \`[TODO: confirm value proposition]\`)
- KPIs (or \`[TODO: confirm KPIs]\`)
- Business Stakeholders (or \`[TODO: confirm stakeholders]\`)
- Dependencies, Interlocks
- Applicable Personas
- Acceptance Criteria (one AC per distinct requirement row/statement)

## 5. AC Rules

- Business/functional level — no technical implementation details.
- Format: AC[N]: Given that I am [persona], when [condition], then [result].
- Collapse near-duplicates, flag exact duplicates.
- Ambiguous rows → \`[TODO: confirm — ambiguous requirement: <summary>]\`.

## 6. Output Feature Artifact

Use the standard Feature template structure. Flag contradictions, duplicates, and input-quality issues.
`),
        'flow-analysis.md': workflow(version, 'Flow Analysis — Process flow to Feature', `
## 1. Gather Input

Ask: "Please provide the business process flow — as a text description or diagram markup."

## 2. Parse Flow

Identify:
- Actors / roles → Applicable Personas
- Primary business capability → Feature Summary
- Decision points and outcomes → derive ACs
- Entry conditions and terminal states → scope boundary
- Systems or external entities → Dependencies and Interlocks

## 3. Derive ACs from Decision Points

Each meaningful decision point or outcome = one AC.
- Focus on business-observable results, not internal system steps.
- Format: AC[N]: Given that I am [persona], when [condition], then [result].
- Ambiguous paths → \`[TODO: confirm — ambiguous path: <description>]\`.

## 4. Flag Flow Gaps

- Unreachable paths
- Missing error/exception handling
- Ambiguous decision conditions

## 5. Output Feature Artifact

Use the standard Feature template. Include Flow Gaps & Flags section.
`),
        'refinement-analysis.md': workflow(version, 'Refinement Analysis — Session notes to Feature', `
## 1. Gather Input

Ask: "Please paste the refinement transcript or session notes."

## 2. Parse Input

- **Verbatim transcript**: distinguish agreed items from open discussions, ignore filler.
- **Bullet-point notes**: infer structure, do not invent details not present.

## 3. Extract Agreed vs Unresolved

Separate:
- **Agreed decisions** → become confirmed ACs
- **Discussed but unresolved** → \`[TODO: confirm — discussed but unresolved: <summary>]\`
- **Contradictions** → flag explicitly

## 4. Derive Feature

- Feature Summary: synthesize, do not copy verbatim.
- Value Proposition: often stated early as the "why".
- KPIs, Stakeholders, Dependencies, Personas, ACs.

## 5. Output Feature Artifact

Use the standard Feature template. Include Flags section for contradictions and unresolved items.
`),
        'scope-analysis.md': workflow(version, 'Scope Analysis — Feature to classified scope', `
## 1. Gather Input

Require a Feature artifact. If not provided, ask or recommend the input/flow/refinement analyzer.

## 2. Trace Components

Trace against \`force-app/main/default\`:

**OmniStudio**: entry OmniScript → embedded FlexCards → child OmniScripts → Integration Procedures.
**Flow Builder**: trigger object/context → subflows → Platform Events/CDC.
**Experience Cloud**: site → FlexiPages → visibility rules → audience targeting.

## 3. Classify Each AC

- **Test-Only**: already implemented. Cite metadata file path as evidence.
- **Requires Work**: sub-classify as Dev, Config, Integration, Translation, or Data Migration.
- Cannot determine → \`[TODO: confirm …]\`.

## 4. Apply Metadata Patterns

- FlexCard routing: read \`.ouc-meta.xml\`, locate \`data-conditions\`, document verbatim.
- FlexCard versioning: check \`isActive\`.
- FlexiPage visibility: data-driven = org-default (Test-Only), user-context = persona-restricted (Requires Work).
- Record type visibility: \`<visible>false</visible>\` = Requires Work.
- IP reuse: no modification = Integration: No.
- FLS: check field-level permissions.

## 5. Set Work Type Flags

- Salesforce Dev/Config: Yes | No
- Integration: Yes | No — [rationale]
- Translation: Yes | No — [target languages or [TODO: confirm]]
- Data Migration: Yes | No
- Wireframes: Yes | No

## 6. Output Scope Analysis Artifact

Standard structure: Overview, Traced Components, AC Classification table, Work Type Flags, Conflicts & Open Questions, Next Step.
`),
        'solution-design.md': workflow(version, 'Solution Design — Scope Analysis to Technical Solution', `
## 1. Validate Inputs

Require a Scope Analysis artifact. Use only ACs marked **Requires Work**.

## 2. Validate Metadata Per AC

For each Requires-Work AC, validate in \`force-app/main/default\`:
- Page layout assignments (profile/permission set \`<layout>\` entries)
- FlexiPage visibility (org-default vs persona-restricted)
- Record type visibility (\`<recordTypeVisibilities>\`)
- FlexCard routing (\`data-conditions\` in \`.ouc-meta.xml\`)
- FlexCard versioning (\`isActive\`)
- OmniScript reuse, IP reuse, FLS

## 3. Per-AC Technical Approach

For each AC:
- Approach (one paragraph, grounded in metadata)
- Technical bullets (cite file paths, existing values verbatim)
- Risks / Dependencies
- Open items: \`[TODO: confirm …]\` or None

## 4. Cross-cutting Concerns

- FLS, Security/Sharing, Performance/Governor Limits, Versioning

## 5. New Field Recommendations (if any)

Per field: Label, API Name (cite naming pattern), Type, Description, Integration use, Permission sets.

## 6. Output Technical Solution Artifact

Standard structure: Source Reference, Per-AC Technical Approach, Cross-cutting Concerns, New Field Recommendations, Open Questions.
`),
        'story-templating.md': workflow(version, 'Story Templating — Technical Solution to User Stories', `
## 1. Validate Inputs

Require Scope Analysis + Technical Solution artifacts. If missing, recommend upstream workflow.

## 2. Determine Story Types

Based on Work Type Flags:
- **Execution**: Salesforce Dev/Config = Yes
- **Integration**: Integration = Yes (new IPs/endpoints only)
- **Translation** (per language): Translation = Yes

## 3. Generate Stories (per type)

Sections: Title, Description, Assumptions, Impacted Area, Functional Design, Wireframes, Technical Notes, Integration Needs, Data Migration, Dependencies/Enablers, Applicable Personas, Acceptance Criteria.

Key rules:
- Test-Only ACs → Assumptions only, NOT in AC list.
- Re-number ACs sequentially (no gaps).
- AC format: Given that I am [persona], when [trigger], then [result].
  **Technical Details:** (only if technical bullets exist)
  - [bullet]
- Error translations → Translation story.
- Functional Design: draft when scope is config-only or OmniStudio changes are well-understood.

## 4. Output User Stories

One clearly separated section per story type.
`),
        'test-case-generation.md': workflow(version, 'Test Case Generation — User Story to QA-ready test cases', `
## 1. Validate Inputs

Require a User Story (Execution, Integration, or Translation).

## 2. Generate Test Categories Per AC

For each AC, generate four test types:
1. **Positive path**: happy path for the applicable persona.
2. **Negative path**: invalid input, permission denial, unauthorized persona.
3. **Edge case**: boundary conditions, empty states, max values.
4. **Regression**: verify unchanged areas still work (critical for OmniStudio reuse, FlexCard versioning, config changes).

## 3. Component Mapping

Each test must cite the specific component, profile, permission set, or metadata file it exercises.

## 4. Test-Only AC Coverage

If the story Assumptions list Test-Only ACs, generate test cases for those too (they still need QA coverage).

## 5. AC Format

- Gherkin: Given that I am [persona], when [condition], then [result].
- Components exercised: [name — file path]
- Preconditions: [grounded or None]

## 6. Output Test Cases Artifact

Standard structure: Source Reference, Test Cases (per AC with TC-AC#-P1/N1/E1/R1), Cross-cutting Test Considerations, Flags, Open Questions.
`),
    };
}
//# sourceMappingURL=sa.js.map