fraim-framework 2.0.56 → 2.0.58

package/dist/registry/workflows/business-development/ideate-business-opportunity.md

@@ -1,55 +0,0 @@
-# Workflow: ideate-business-opportunity
-
-**Path:** `workflows/business-development/ideate-business-opportunity.md`
-
----
-
-# Ideate Business Opportunity Phase
-
-## INTENT
-To help founders and product owners navigate the broad, fuzzy front-end of product development. This workflow guides the transition from a "vague space" to "concrete feature deliverables" through interactive brainstorming and research.
-
-## PRINCIPLES
-- **Interactive Exploration**: This is not a one-shot process. It requires multiple cycles of feedback.
-- **Founder-Led**: The founder's intuition is the compass; the agent provides the map and vehicle.
-- **Outcome-Oriented**: The goal is NOT just a list of ideas, but a prioritized, repo-ready backlog.
-- **Divergent Thinking**:
-    - **Defer Judgment**: Do not criticize or discard ideas in the early stages.
-    - **Go for Volume**: Quantity often leads to quality. Aim for a wide range of options.
-    - **Cross-Pollinate**: Combine unrelated concepts or industries to find unique angles.
-    - **Challenge Constraints**: Ask "What if X wasn't a limitation?"
-    - **Interactive Refinement**: Use feedback to branch into new directions, even if they seem tangential.
-
-## IDEATION WORKFLOW
-
-### Step 1: Broad Mapping (Divergent)
-- Ask the founder for their initial "Spark" or "Space".
-- **Exploration Protocol**: 
-    - When an idea is proposed, respond with 3-5 distinct "What if" scenarios or variations.
-    - Avoid saying "That's not possible" or "That's too expensive" during this stage.
-    - Use tools to describe or visualize the space before narrowing down.
-- Generate 3-5 distinct sub-spaces or "angles" within that spark.
-- **Exit Criteria**: Founder chooses 1-2 directions to explore further.
-
-### Step 2: Interactive Research & Validation
-- For the chosen directions, research:
-    - Existing competitors (even indirect ones).
-    - Potential user personas.
-    - Technical feasibility (high-level).
-- Present findings and ask for "Pivot or Persevere" feedback.
-
-### Step 3: Feature Synthesis (Convergent)
-- Based on the validated direction, brainstorm a set of potential features.
-- Map features against: **Complexity** vs. **Value**.
-- **Exit Criteria**: Founder approves a "Hero" feature and 3-5 supporting features.
-
-### Step 4: Repository Documentation
-- Formalize the findings into a report.
-- **ACTION**: Call `get_fraim_file({ path: "templates/business-development/IDEATION-REPORT-TEMPLATE.md" })`.
-- Create `docs/ideation/{YYYYMMDD}-{project-name}.md`.
-- **Outcome**: A file that a PM agent can use to write `specs`.
-
-## OUTPUT
-- `docs/ideation/[project].md`
-- Prioritized Feature Backlog
-- High-level Vision & Persona Map

package/dist/registry/workflows/business-development/price-product.md

@@ -1,325 +0,0 @@
-## INTENT
-
-To create a comprehensive **pricing + packaging strategy** for any product that:
-
-* clarifies who the product is for and what outcomes it delivers,
-* defines SKUs, tiers, add-ons, and the pricing metric,
-* ties pricing to unit economics and scalability,
-* and positions the product clearly against competitors and substitutes.
-
----
-
-## PRINCIPLES
-
-* **Outcome-first**: Price and packaging must map to customer outcomes, not features
-* **Simple packaging**: Fewer SKUs, clearer upgrade path, lower decision friction
-* **Credible claims**: Use evidence, ranges, and benchmarks; avoid brittle promises
-* **Economic grounding**: Every SKU must connect to COGS, margin targets, and scalability limits
-* **Competitive honesty**: Don’t invent competitor pricing; cite sources or state “not public”
-* **Procurement-friendly**: Prefer predictable add-ons/tiers over opaque metered token pricing
-* **Reusable framework**: The same structure should work for B2B, B2C, SaaS, services, and hybrid models
-* **Citations required**: All competitive facts should be sourced with dates
-
----
-
-## WORKFLOW OVERVIEW
-
-This workflow produces a single comprehensive document (`docs/business-development/pricing-strategy.md`) that follows the template in `templates/business-development/PRICING-STRATEGY-TEMPLATE.md`.
-
----
-
-## STEP-BY-STEP WORKFLOW
-
-### Step 1: Product Context Gathering
-
-**Objective:** Understand the product, buyer, and constraints.
-
-**Actions:**
-
-1. Capture product one-liner and primary outcomes
-2. Identify who pays vs who uses (buyer vs end user)
-3. Define product type: SaaS, usage-based, services, hybrid
-4. Capture current stage: MVP/beta/GA and current pricing (if any)
-5. Capture business constraints:
-
-   * margin targets
-   * delivery capacity (if services/hybrid)
-   * sales motion (self-serve vs sales-led)
-   * contract constraints (annual, PO, procurement)
-
-**Output:** Product context section (10–20 bullets)
-
----
-
-### Step 2: Customer Segmentation (ICP + willingness-to-pay)
-
-**Objective:** Identify 3–7 segments with different value and pricing sensitivity.
-
-**Process:**
-
-1. Brainstorm segments by pain intensity and frequency
-2. Score each segment:
-
-   * Pain intensity
-   * Frequency of use
-   * Budget owner clarity
-   * Willingness to pay
-   * Ease of reach (distribution)
-   * Competitive alternatives
-3. Select 2–4 priority segments (tip-of-the-spear)
-4. For each segment document:
-
-   * Customer profile
-   * Job-to-be-done
-   * Core pains
-   * Current alternatives
-   * Buying process and budget source
-   * Success metrics they care about
-
-**Output:** Segment cards + segment comparison table
-
----
-
-### Step 3: Outcome Narrative (the “why” before pricing)
-
-**Objective:** Build an exec-readable narrative that sets up the pricing table.
-
-**Actions:**
-
-1. Write a headline framing value (speed, cost, quality, risk reduction, revenue)
-2. Explain why outcomes vary with usage maturity (if applicable)
-3. Describe the customer journey in 3 “paths” or “maturity levels” (optional but powerful):
-
-   * Self-serve power user
-   * Guided/coached adopter
-   * Managed delivery / done-for-you (if offered)
-4. Add a clear CTA (“If you’re here and want to be there…”)
-
-**Output:** One-page narrative suitable for a brochure
-
----
-
-### Step 4: Define Packaging (SKUs, tiers, and boundaries)
-
-**Objective:** Create a SKU/tier map that is simple and scalable.
-
-**Actions:**
-
-1. Define 3–6 SKUs by **customer need** (e.g., role-based, module-based, team-based, use-case-based)
-2. Define tiers (Good/Better/Best) or maturity tiers (Self-serve / Guided / Managed)
-3. For each SKU/tier define:
-
-   * Outcomes delivered
-   * Included capabilities
-   * Exclusions/limits (what’s not included)
-   * Primary success metrics
-   * Who it’s for (buyer/user)
-4. Ensure upgrade path is explicit:
-
-   * When to move up a tier
-   * What triggers expansion (more users, more volume, more scope)
-
-**Output:** SKU catalog + tier comparison table
-
----
-
-### Step 5: Choose a Pricing Metric (what you charge “per”)
-
-**Objective:** Pick a pricing unit that scales with value and is hard to game.
-
-**Common metrics (choose 1 primary):**
-
-* Per user / seat
-* Per team / workspace
-* Per project
-* Per workflow/run
-* Per asset (e.g., report, doc, build, analysis)
-* Per integration
-* % of spend / % of savings (rare; needs strong proof)
-* Tiered capacity bundles (recommended for predictability)
-
-**Selection criteria:**
-
-* Aligns with value
-* Understandable to buyers
-* Predictable billing
-* Resistant to abuse
-* Matches cost-to-serve drivers
-
-**Output:** Pricing metric decision + rationale + alternatives rejected
-
----
-
-### Step 6: Build the Price List (tables first, numbers second)
-
-**Objective:** Produce clean pricing tables and packaging rules.
-
-**Actions:**
-
-1. Start with a single “hero” table (e.g., 3 columns × 3 rows):
-
-   * Columns = tiers/maturity levels
-   * Rows = what you get (outcomes), what you save/earn, what you pay
-2. Expand into:
-
-   * SKU × tier grid (if needed)
-   * Add-on list
-3. Define discounting:
-
-   * annual prepay discount
-   * volume discount principles
-   * partner/channel margins (if relevant)
-
-**Output:** Pricing tables + add-ons + discount rules
-
----
-
-### Step 7: Unit Economics + Scalability Model
-
-**Objective:** Ensure pricing is profitable, defensible, and scalable.
-
-**Actions:**
-
-1. Identify COGS drivers:
-
-   * compute/infrastructure
-   * support burden
-   * onboarding/training
-   * professional services / delivery labor
-   * third-party fees
-2. For each SKU/tier estimate:
-
-   * expected usage / volume
-   * expected support hours
-   * expected compute cost
-   * gross margin target
-3. Model edge cases:
-
-   * power users
-   * low-usage churners
-   * heavy-support customers
-4. Define guardrails:
-
-   * caps
-   * fair-use limits
-   * paid add-on packs for overflow
-   * staffing ratios (if managed services)
-
-**Output:** Unit economics assumptions table + margin estimates by SKU/tier
-
----
-
-### Step 8: Competitive Landscape & Positioning (research required)
-
-**Objective:** Build a credible pricing/positioning story vs alternatives.
-
-**Actions:**
-
-1. Identify 10–20 competitors/substitutes across:
-
-   * direct competitors
-   * adjacent tools
-   * “do nothing/manual”
-   * agencies/contractors (if relevant)
-2. For each competitor:
-
-   * what they sell
-   * who buys
-   * pricing model (cite sources, include dates)
-   * strengths/weaknesses vs your product
-3. Synthesize:
-
-   * differentiation pillars (3–5)
-   * win/loss reasons
-   * objection handling talk tracks
-
-**Output:** Competitive matrix + positioning section (with citations)
-
----
-
-### Step 9: Risks, Objections, and Mitigations
-
-**Objective:** Preempt the hardest questions and reduce churn risk.
-
-**Actions:**
-
-* Identify 5–10 risks:
-
-  * credibility of claims
-  * adoption friction
-  * pricing confusion
-  * margin erosion
-  * scaling services
-  * procurement/security concerns
-  * competitor response
-* For each:
-
-  * impact
-  * mitigation
-  * owner
-  * measurable leading indicator
-
-**Output:** Risk table
-
----
-
-### Step 10: Validation Plan (pricing experiments + rollout)
-
-**Objective:** Test assumptions quickly before locking prices.
-
-**Actions:**
-
-1. Define experiments:
-
-   * price sensitivity interviews (Van Westendorp / Gabor-Granger style)
-   * landing page A/B price anchoring
-   * pilot offers with 2–3 packaging variants
-   * sales-led quote testing
-2. Define metrics:
-
-   * conversion
-   * activation/time-to-value
-   * expansion
-   * churn
-   * support burden
-   * gross margin
-3. Create 30/60/90 day plan
-
-**Output:** Validation plan + timeline + decision points
-
----
-
-## References
-- All citations with date + URL
-```
-
----
-
-## QUALITY CHECKLIST
-
-### Content
-
-* [ ] Pricing is outcome-first, not feature-first
-* [ ] SKUs/tiers are simple with a clear upgrade path
-* [ ] Pricing metric is understandable and predictable
-* [ ] Add-ons reduce edge-case margin risk
-* [ ] Sales motion is supported (self-serve vs sales-led)
-
-### Economics
-
-* [ ] COGS drivers identified and bounded
-* [ ] Gross margin targets by tier are explicit
-* [ ] Guardrails (caps/add-ons) prevent abuse and margin collapse
-
-### Competitive
-
-* [ ] No invented competitor pricing
-* [ ] Citations + dates included for competitive facts
-* [ ] Win/loss reasons are honest and actionable
-
-### Validation
-
-* [ ] At least 3 pricing experiments defined
-* [ ] Metrics are clear and decision points are scheduled
-
----

package/dist/registry/workflows/compliance/detect-compliance-requirements.md

@@ -1,78 +0,0 @@
-# Detect Compliance Requirements
-
-## INTENT
-Analyze feature descriptions to detect applicable compliance frameworks, then update project configuration.
-
-## OUTCOME
-- Project `.fraim/config.json` updated with confirmed regulations list
-- Clear understanding of which compliance frameworks apply
-
-## WORKFLOW
-
-### Step 1: Analyze Feature Description and Context
-Look for compliance indicators from multiple sources:
-
-**Feature Description Analysis**:
-- **Financial**: payment, transaction, receipt, disbursement, funds, money → FinRA
-- **UI**: interface, customer-facing, website, dashboard, form → WCAG  
-- **Data**: personal data, customer information, pii, sensitive data → GDPR
-- **Payment Processing**: credit card, payment processing, card data → PCI DSS
-
-**Deep Context Analysis**:
-- Read existing business documentation and plans
-- Analyze codebase for compliance-related implementations
-- Review existing compliance documentation
-- Consider user stories and acceptance criteria
-
-### Step 2: Check Project Industry
-Read `.fraim/config.json` and check `project.industry`:
-- `financial-services` → Likely FinRA, State Financial
-- `healthcare` → Likely HIPAA
-- `e-commerce` → Likely PCI DSS, GDPR
-- `software-development` → Likely SOC 2, ISO 27001
-
-### Step 3: Present Detection Results
-Show user detected regulations with reasoning.
-
-### Step 4: User Confirmation
-Ask user to confirm which regulations apply.
-
-**Important**: Updating the config will cause future specs to automatically include compliance requirements for these regulations.
-
-### Step 5: Update Configuration
-Once user confirms, update `.fraim/config.json` (preserving existing content):
-```json
-{
-  "compliance": {
-    "regulations": ["finra", "wcag", "gdpr"],
-    "compliance_specifications": {
-      "finra": "https://www.finra.org/rules-guidance",
-      "wcag": "https://www.w3.org/WAI/WCAG21/quickref/",
-      "gdpr": "https://gdpr-info.eu/"
-    }
-  }
-}
-```
-
-**Standard Reference URLs by Regulation:**
-- **finra**: https://www.finra.org/rules-guidance
-- **pci**: https://www.pcisecuritystandards.org/standards/
-- **wcag**: https://www.w3.org/WAI/WCAG21/quickref/
-- **gdpr**: https://gdpr-info.eu/
-- **ccpa**: https://oag.ca.gov/privacy/ccpa
-- **soc2**: https://www.aicpa.org/resources/landing/system-and-organization-controls-soc-suite-of-services
-- **iso27001**: https://www.iso.org/standard/27001
-- **hipaa**: https://www.hhs.gov/hipaa/for-professionals/security/laws-regulations/index.html
-- **fedramp**: https://www.fedramp.gov/documents/
-
-**Note**: Only include regulations and URLs that apply to the project. Users can override URLs with company-specific documentation.
-
-### Step 6: Next Steps
-Tell user to add or update compliance_specifications with document links:
-```json
-{
-  "compliance_specifications": [
-    {"<regulation_name>": "<doc_link_or_location"}
-  ]
-}
-```

package/dist/registry/workflows/compliance/generate-audit-evidence.md

@@ -1,75 +0,0 @@
-# Generate Audit Evidence
-
-## INTENT
-Generate compliance audit documentation by analyzing implementations against regulatory requirements.
-
-## OUTCOME
-- Audit documentation generated
-- Evidence mapped to regulatory requirements from compliance_specifications
-
-## WORKFLOW
-
-### Step 1: Read Compliance Configuration
-Read `.fraim/config.json`:
-```json
-{
-  "compliance": {
-    "regulations": ["finra", "wcag"],
-    "compliance_specifications": [
-      {"name": "FinRA Requirements", "pointer": "https://company.com/finra-requirements.pdf"},
-      {"name": "WCAG Standards", "pointer": "https://company.com/accessibility-standards.pdf"}
-    ]
-  }
-}
-```
-
-### Step 2: Get Evidence Files from User
-Ask user which files/implementations to analyze for compliance evidence.
-
-### Step 3: Analyze Evidence Against Requirements
-For each regulation:
-1. **Reference Requirements Document**: Tell agent "Ensure this implementation abides by the requirements specified in [pointer]"
-2. **Analyze Implementation**: Review provided files against the specification document
-3. **Document Evidence**: Map code/implementations to regulatory requirements
-4. **Create Evidence Document**: Generate detailed compliance evidence document
-
-### Step 4: Generate Audit Reports and Evidence Document
-Create compliance reports by regulation and a comprehensive evidence document:
-
-**Evidence Document Structure**:
-```markdown
-# Compliance Evidence Report - [Feature Name]
-
-## Executive Summary
-- Overall compliance status: [X]% compliant
-- Regulations analyzed: [list]
-- Critical gaps: [number]
-
-## Detailed Evidence by Regulation
-
-### FinRA Compliance
-**Requirements Source**: [FinRA Requirements](https://company.com/finra-requirements.pdf)
-**Evidence Analysis**:
-- ✅ **COMPLIANT**: Transaction Logging in `src/services/transaction-logger.ts`
-  - Evidence: Code implements required fields (date, amount, type, account)
-  - Verification: Unit tests pass, audit trail functional
-- ❌ **NON-COMPLIANT**: Record Retention Policy
-  - Gap: No automated retention policy implemented
-  - Required Action: Implement 3-year retention automation
-```
-
-**Example FinRA Report**:
-```markdown
-## FinRA Compliance Evidence
-**Requirements Source**: [FinRA Requirements](https://company.com/finra-requirements.pdf)
-**Agent Instruction**: Ensure all implementations abide by requirements specified in the above document.
-
-**Implementation Analysis**:
-- ✅ Transaction Logging: `src/services/transaction-logger.ts` - Compliant
-- ❌ Record Retention: Missing automated retention policy
-```
-
-### Step 5: Reference Compliance Specifications
-Always reference the original compliance specification:
-**Requirement Source**: As specified in [document name](pointer URL)
-**Agent Instruction**: Ensure all implementations abide by the requirements specified in the above document