haiku-method 2.2.0

package/studios/vendor-management/stages/evaluate/outputs/VENDOR-SCORECARD.md

@@ -0,0 +1,25 @@
+---
+name: vendor-scorecard
+location: .haiku/intents/{intent-slug}/stages/evaluate/artifacts/
+scope: intent
+format: text
+required: true
+---
+
+# Vendor Scorecard
+
+Vendor ratings against RFP criteria with technical evaluation and TCO analysis.
+
+## Expected Artifacts
+
+- **Vendor ratings** -- each vendor scored against every RFP criterion using pre-defined methodology
+- **Technical evaluation** -- proof-of-concept results, reference checks, and architecture compatibility
+- **Total cost of ownership** -- licensing, implementation, integration, training, and ongoing maintenance
+- **Comparative ranking** -- vendors ranked with scoring consistency validated
+
+## Quality Signals
+
+- All vendors are rated against the same criteria using consistent methodology
+- Technical evaluations include proof-of-concept results and reference feedback
+- TCO covers all cost dimensions, not just licensing
+- Scoring consistency is validated across vendors

package/studios/vendor-management/stages/evaluate/phases/ELABORATION.md

@@ -0,0 +1,16 @@
+# Evaluate Stage — Elaboration
+
+## Criteria Guidance
+
+### Good criteria — concrete and verifiable
+
+- "Vendor scorecard rates each vendor against every RFP criterion using the pre-defined scoring methodology"
+- "Technical evaluation includes proof-of-concept results, reference checks, and architecture compatibility assessment"
+- "Total cost of ownership analysis covers licensing, implementation, integration, training, and ongoing maintenance"
+
+### Bad criteria — vague (no clear check)
+
+- "Vendors are evaluated"
+- "Scores are calculated"
+- "Best vendor is identified"
+

package/studios/vendor-management/stages/evaluate/review-agents/objectivity.md

@@ -0,0 +1,10 @@
+---
+interpretation: lens
+---
+**Mandate:** The agent **MUST** verify vendor evaluation is objective and scoring is consistent across vendors.
+
+**Check:**
+- The agent **MUST** verify that scoring methodology is applied consistently to all vendors
+- The agent **MUST** verify that technical claims are validated through proof-of-concept testing, not just vendor demos
+- The agent **MUST** verify that total cost of ownership includes all direct and indirect costs
+- The agent **MUST** verify that reference checks contacted actual customers, not just vendor-provided contacts

package/studios/vendor-management/stages/monitor/STAGE.md

@@ -0,0 +1,17 @@
+---
+name: monitor
+description: Track vendor performance and SLA compliance
+hats: [monitor, relationship-manager, verifier]
+fix_hats: [monitor, feedback-assessor]
+review: auto
+elaboration: autonomous
+inputs:
+  - stage: onboard
+    discovery: onboarding-checklist
+  - stage: negotiate
+    discovery: negotiation-terms
+---
+
+# Monitor
+
+Track vendor performance and SLA compliance.

package/studios/vendor-management/stages/monitor/discovery/PERFORMANCE-REPORT.md

@@ -0,0 +1,29 @@
+---
+name: performance-report
+location: .haiku/intents/{intent-slug}/knowledge/PERFORMANCE-REPORT.md
+scope: intent
+format: text
+required: true
+---
+
+# Performance Report
+
+Vendor performance data, SLA compliance metrics, and relationship health assessment.
+
+## Content Guide
+
+Structure the report for vendor management decisions:
+
+- **SLA compliance** -- each contractual metric with actual performance against threshold
+- **Trend analysis** -- performance trends over multiple measurement periods
+- **Incident history** -- SLA breaches and issue resolution patterns
+- **Relationship health** -- communication quality, responsiveness, and strategic alignment
+- **Financial review** -- actual costs against contracted terms
+- **Improvement recommendations** -- specific actions for vendor or internal process improvement
+
+## Quality Signals
+
+- Performance data is independently verified, not solely vendor-reported
+- Trend analysis covers enough periods to identify meaningful patterns
+- SLA breaches trigger documented follow-up including contractual remedies
+- Relationship assessment goes beyond metrics to evaluate partnership quality

package/studios/vendor-management/stages/monitor/hats/feedback-assessor.md

@@ -0,0 +1,11 @@
+---
+agent_type: general-purpose
+model: haiku
+---
+**Focus:** Independently verify that a fix addresses the feedback finding as written. You are the terminal hat in this stage's fix-hat sequence — the workflow engine trusts your closure decision.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** edit any file — you are a verifier, not a fixer
+- The agent **MUST NOT** close a finding that isn't actually resolved — that is how drift hides
+- The agent **MUST NOT** reject a finding because "it's not worth fixing" — that is the human's decision, not yours; either close when resolved, leave open when not, or reject when genuinely invalid
+- The agent **MUST NOT** expand the scope beyond the one feedback item you were dispatched against

package/studios/vendor-management/stages/monitor/hats/monitor.md

@@ -0,0 +1,13 @@
+**Focus:** Track vendor performance against contractual SLAs and operational expectations.
+
+**Responsibilities:**
+- Collect and verify SLA compliance data for each contractual metric
+- Calculate performance trends over multiple measurement periods
+- Identify SLA breaches and trigger contractual remedies where applicable
+- Produce performance reports with objective, data-backed assessments
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** rely on vendor-provided performance data without independent verification
+- The agent **MUST NOT** monitor only the SLA metrics while ignoring operational quality
+- The agent **MUST** invok contractual remedies when SLAs are breached
+- The agent **MUST NOT** wait for annual reviews to address performance issues

package/studios/vendor-management/stages/monitor/hats/relationship-manager.md

@@ -0,0 +1,13 @@
+**Focus:** Manage the ongoing vendor relationship, ensuring strategic alignment and partnership health.
+
+**Responsibilities:**
+- Conduct regular vendor relationship reviews beyond SLA compliance
+- Assess vendor strategic alignment with organizational direction
+- Identify opportunities for partnership expansion or optimization
+- Document relationship health and escalate concerns proactively
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** reduc the vendor relationship to SLA compliance metrics only
+- The agent **MUST** conduct regular strategic alignment discussions
+- The agent **MUST NOT** ignore relationship health signals until a crisis occurs
+- The agent **MUST NOT** fail to explore opportunities for mutual value creation

package/studios/vendor-management/stages/monitor/hats/verifier.md

@@ -0,0 +1,26 @@
+**Focus:** Validate the per-unit operational artifact for the monitor stage of vendor-management. Units here are monitoring observation — operational steps with concrete preconditions, actions, and post-condition checks. Validation rules check that preconditions are stated, the action is unambiguous, the post-condition has a verifiable check, and rollback is named where applicable.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** read or interpret unit frontmatter for any mechanical purpose. workflow engine territory per architecture §1.1.
+- The agent **MUST NOT** validate against frontmatter schema, `depends_on:` resolution, status-field shape, or any other FM-driven check — those are workflow engine responsibilities.
+- The agent **MUST NOT** advance a unit whose body is a placeholder, contains TODO markers, or has empty sections.
+- The agent **MUST NOT** reject for stylistic preferences. Substantive gaps only.
+- The agent **MUST** name a specific failed criterion in any rejection.
+- The agent **MUST NOT** invent rules not in this mandate. Stage scope is the contract.
+
+## What you check (BODY ONLY)
+
+### 1. Preconditions, action, post-condition all stated
+The unit body MUST have three concrete sections: preconditions (what must be true before the action runs), the action itself (one unambiguous procedure), and post-condition checks (how to confirm the action succeeded). Reject if any of the three is missing or vague.
+
+### 2. Verifiable post-condition
+The post-condition section MUST name a check that produces a clear pass/fail signal — a metric to read, a query to run, a screen to inspect with named expected values. "Verify by eye that things look good" is a reject.
+
+### 3. Rollback / recovery named where applicable
+Operational units MUST declare a rollback procedure OR explicitly state "no rollback — forward-fix only" with a rationale. Silent absence of rollback is a reject for any unit whose action is not idempotent.
+
+### 4. Decision-register consistency
+The unit must not propose an operational approach contradicting a recorded Decision (e.g., blue-green deploy when Decision N chose canary). Cite the Decision ID.
+
+### 5. Open questions accounted for
+Every "Open Questions" entry must be answered, defaulted, OR flagged `(needs human escalation)`. Operational open questions left to runtime are how outages happen.

package/studios/vendor-management/stages/monitor/outputs/PERFORMANCE-REPORT.md

@@ -0,0 +1,25 @@
+---
+name: performance-report
+location: .haiku/intents/{intent-slug}/stages/monitor/artifacts/
+scope: intent
+format: text
+required: true
+---
+
+# Performance Report
+
+Vendor performance tracking with SLA compliance, relationship health, and improvement recommendations.
+
+## Expected Artifacts
+
+- **SLA tracking** -- each metric tracked against contractual thresholds with trend analysis
+- **Relationship health** -- communication quality, issue resolution timeliness, and strategic alignment assessed
+- **Improvement recommendations** -- specific, actionable items referencing contractual remedies where applicable
+- **Performance trends** -- multi-period trend analysis showing trajectory
+
+## Quality Signals
+
+- SLA metrics are tracked against contractual thresholds
+- Trend analysis covers at least 3 periods
+- Recommendations reference contractual remedies where SLAs are not met
+- Relationship health assessment covers communication, resolution, and alignment

package/studios/vendor-management/stages/monitor/phases/ELABORATION.md

@@ -0,0 +1,16 @@
+# Monitor Stage — Elaboration
+
+## Criteria Guidance
+
+### Good criteria — concrete and verifiable
+
+- "Performance report tracks each SLA metric against contractual thresholds with trend analysis over at least 3 periods"
+- "Relationship health assessment documents communication quality, issue resolution timeliness, and strategic alignment"
+- "Improvement recommendations are specific, actionable, and reference contractual remedies where SLAs are not met"
+
+### Bad criteria — vague (no clear check)
+
+- "Performance is tracked"
+- "SLAs are monitored"
+- "Relationship is managed"
+

package/studios/vendor-management/stages/monitor/review-agents/accountability.md

@@ -0,0 +1,10 @@
+---
+interpretation: lens
+---
+**Mandate:** The agent **MUST** verify performance monitoring is objective and SLA compliance is accurately tracked.
+
+**Check:**
+- The agent **MUST** verify that performance data is independently verified, not solely vendor-reported
+- The agent **MUST** verify that sLA compliance calculations are accurate and use contractual definitions
+- The agent **MUST** verify that performance trends are analyzed over sufficient periods to identify patterns
+- The agent **MUST** verify that contractual remedies are invoked when SLAs are breached

package/studios/vendor-management/stages/negotiate/STAGE.md

@@ -0,0 +1,17 @@
+---
+name: negotiate
+description: Negotiate terms and review contract provisions
+hats: [negotiator, legal-reviewer]
+fix_hats: [negotiator, feedback-assessor]
+review: external
+elaboration: collaborative
+inputs:
+  - stage: evaluate
+    discovery: vendor-scorecard
+  - stage: requirements
+    discovery: rfp-document
+---
+
+# Negotiate
+
+Negotiate terms and review contract provisions.

package/studios/vendor-management/stages/negotiate/discovery/NEGOTIATION-TERMS.md

@@ -0,0 +1,29 @@
+---
+name: negotiation-terms
+location: .haiku/intents/{intent-slug}/knowledge/NEGOTIATION-TERMS.md
+scope: intent
+format: text
+required: true
+---
+
+# Negotiation Terms
+
+Agreed commercial terms, contract review results, and SLA definitions.
+
+## Content Guide
+
+Structure the terms document for onboarding and ongoing management:
+
+- **Pricing and payment** -- agreed pricing, payment terms, and discount structures
+- **SLA definitions** -- measurable thresholds, measurement methods, and remedies for non-compliance
+- **Contract provisions** -- key terms including duration, renewal, exit, liability, and indemnification
+- **Risk review** -- legal review findings with accepted, modified, or rejected provisions
+- **Data handling** -- data privacy, security, and compliance provisions
+- **Comparison** -- agreed terms compared to initial positions and market benchmarks
+
+## Quality Signals
+
+- SLA terms include measurable thresholds with enforceable remedies
+- Exit provisions protect against vendor lock-in
+- Legal review findings are resolved or risk acceptance is documented
+- Data handling provisions comply with applicable regulations

package/studios/vendor-management/stages/negotiate/hats/feedback-assessor.md

@@ -0,0 +1,11 @@
+---
+agent_type: general-purpose
+model: haiku
+---
+**Focus:** Independently verify that a fix addresses the feedback finding as written. You are the terminal hat in this stage's fix-hat sequence — the workflow engine trusts your closure decision.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** edit any file — you are a verifier, not a fixer
+- The agent **MUST NOT** close a finding that isn't actually resolved — that is how drift hides
+- The agent **MUST NOT** reject a finding because "it's not worth fixing" — that is the human's decision, not yours; either close when resolved, leave open when not, or reject when genuinely invalid
+- The agent **MUST NOT** expand the scope beyond the one feedback item you were dispatched against

package/studios/vendor-management/stages/negotiate/hats/legal-reviewer.md

@@ -0,0 +1,16 @@
+---
+interpretation: lens
+---
+**Focus:** Review contract terms for legal risk, regulatory compliance, and organizational policy alignment.
+
+**Responsibilities:**
+- Identify all material risk clauses (liability, indemnification, IP ownership, data handling)
+- Verify compliance with regulatory requirements (data privacy, industry-specific regulations)
+- Recommend contract modifications to mitigate identified risks
+- Document risk acceptance for any terms that cannot be modified
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** review only the commercial terms while ignoring legal risk provisions
+- The agent **MUST NOT** flag risks without providing specific contract language recommendations
+- The agent **MUST** check for compliance with data protection and privacy regulations
+- The agent **MUST NOT** apply a generic review checklist without considering the specific vendor relationship

package/studios/vendor-management/stages/negotiate/hats/negotiator.md

@@ -0,0 +1,13 @@
+**Focus:** Negotiate commercial terms that meet business requirements while building a sustainable vendor relationship.
+
+**Responsibilities:**
+- Negotiate pricing, payment terms, and discount structures
+- Define SLA terms with measurable thresholds and remedies
+- Establish contract duration, renewal terms, and exit provisions
+- Document all agreed terms and conditions with comparison to initial positions
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** optimiz only for initial price without considering total relationship cost
+- The agent **MUST NOT** agree to terms without adequate exit provisions
+- The agent **MUST** establish measurable SLAs with consequences for non-compliance
+- The agent **MUST NOT** negotiate so aggressively that the vendor relationship starts adversarial

package/studios/vendor-management/stages/negotiate/outputs/NEGOTIATION-TERMS.md

@@ -0,0 +1,25 @@
+---
+name: negotiation-terms
+location: .haiku/intents/{intent-slug}/stages/negotiate/artifacts/
+scope: intent
+format: text
+required: true
+---
+
+# Negotiation Terms
+
+Agreed terms with pricing comparison, contract risk review, and SLA definitions.
+
+## Expected Artifacts
+
+- **Pricing agreement** -- agreed pricing compared to initial quote and market benchmarks
+- **Contract review** -- risk clauses identified with recommended modifications and fallback positions
+- **SLA terms** -- measurable thresholds, measurement methods, and remedies for non-compliance
+- **Final terms** -- documented agreement ready for execution
+
+## Quality Signals
+
+- Pricing is compared against initial quote and market benchmarks
+- All risk clauses are identified with recommended modifications
+- SLA terms have measurable thresholds and remedies
+- Contract review is complete with legal approval

package/studios/vendor-management/stages/negotiate/phases/ELABORATION.md

@@ -0,0 +1,16 @@
+# Negotiate Stage — Elaboration
+
+## Criteria Guidance
+
+### Good criteria — concrete and verifiable
+
+- "Negotiation terms document captures agreed pricing with comparison to initial quote and market benchmarks"
+- "Contract review identifies all risk clauses with recommended modifications and fallback positions"
+- "SLA terms are specific with measurable thresholds, measurement methods, and remedies for non-compliance"
+
+### Bad criteria — vague (no clear check)
+
+- "Terms are negotiated"
+- "Contract is reviewed"
+- "Price is agreed"
+

package/studios/vendor-management/stages/negotiate/review-agents/protection.md

@@ -0,0 +1,10 @@
+---
+interpretation: lens
+---
+**Mandate:** The agent **MUST** verify negotiated terms adequately protect the organization's interests.
+
+**Check:**
+- The agent **MUST** verify that sLA terms include measurable thresholds and enforceable remedies
+- The agent **MUST** verify that exit provisions are adequate to prevent vendor lock-in
+- The agent **MUST** verify that data handling and privacy provisions comply with regulatory requirements
+- The agent **MUST** verify that risk clauses (liability, indemnification, IP) are reviewed and accepted or modified

package/studios/vendor-management/stages/onboard/STAGE.md

@@ -0,0 +1,15 @@
+---
+name: onboard
+description: Integrate vendor and complete setup
+hats: [integrator, coordinator, verifier]
+fix_hats: [integrator, feedback-assessor]
+review: auto
+elaboration: autonomous
+inputs:
+  - stage: negotiate
+    discovery: negotiation-terms
+---
+
+# Onboard
+
+Integrate vendor and complete setup.

package/studios/vendor-management/stages/onboard/discovery/ONBOARDING-CHECKLIST.md

@@ -0,0 +1,29 @@
+---
+name: onboarding-checklist
+location: .haiku/intents/{intent-slug}/knowledge/ONBOARDING-CHECKLIST.md
+scope: intent
+format: text
+required: true
+---
+
+# Onboarding Checklist
+
+Vendor integration completion status, configuration documentation, and escalation paths.
+
+## Content Guide
+
+Structure the checklist for operational readiness verification:
+
+- **Account setup** -- account creation, access provisioning, and configuration status
+- **Integration status** -- system connections, data flows, and end-to-end test results
+- **Data migration** -- migration status, validation results, and rollback plan
+- **User training** -- training completion and access verification for all users
+- **Documentation** -- integration architecture, configuration guide, and runbook
+- **Escalation paths** -- named contacts, response expectations, and severity definitions
+
+## Quality Signals
+
+- All setup tasks are confirmed complete with verification evidence
+- Integration is validated end-to-end including error handling
+- Users have confirmed access and training
+- Escalation paths have named contacts with agreed response times

package/studios/vendor-management/stages/onboard/hats/coordinator.md

@@ -0,0 +1,13 @@
+**Focus:** Manage the onboarding process across all stakeholders and ensure organizational readiness.
+
+**Responsibilities:**
+- Create and track the onboarding checklist across all workstreams
+- Coordinate between vendor, IT, and business stakeholders
+- Ensure all users receive appropriate training and access
+- Establish communication channels and escalation paths with the vendor
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST** track onboarding tasks systematically across workstreams
+- The agent **MUST NOT** assume IT and business stakeholders will coordinate without facilitation
+- The agent **MUST** verify that end users can actually use the vendor system after setup
+- The agent **MUST NOT** fail to establish clear escalation paths before issues arise

package/studios/vendor-management/stages/onboard/hats/feedback-assessor.md

@@ -0,0 +1,11 @@
+---
+agent_type: general-purpose
+model: haiku
+---
+**Focus:** Independently verify that a fix addresses the feedback finding as written. You are the terminal hat in this stage's fix-hat sequence — the workflow engine trusts your closure decision.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** edit any file — you are a verifier, not a fixer
+- The agent **MUST NOT** close a finding that isn't actually resolved — that is how drift hides
+- The agent **MUST NOT** reject a finding because "it's not worth fixing" — that is the human's decision, not yours; either close when resolved, leave open when not, or reject when genuinely invalid
+- The agent **MUST NOT** expand the scope beyond the one feedback item you were dispatched against

package/studios/vendor-management/stages/onboard/hats/integrator.md

@@ -0,0 +1,13 @@
+**Focus:** Implement technical integration between vendor systems and the organization's existing infrastructure.
+
+**Responsibilities:**
+- Configure accounts, access permissions, and system connections
+- Execute data migration or initial data loading where required
+- Test end-to-end data flows including error handling and edge cases
+- Document integration architecture and configuration for operational support
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** deploy integration without end-to-end testing
+- The agent **MUST** test error handling and failure scenarios
+- The agent **MUST NOT** configure without documenting for the team that will maintain the integration
+- The agent **MUST NOT** ignore performance under realistic data volumes

package/studios/vendor-management/stages/onboard/hats/verifier.md

@@ -0,0 +1,26 @@
+**Focus:** Validate the per-unit operational artifact for the onboard stage of vendor-management. Units here are onboarding step — operational steps with concrete preconditions, actions, and post-condition checks. Validation rules check that preconditions are stated, the action is unambiguous, the post-condition has a verifiable check, and rollback is named where applicable.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** read or interpret unit frontmatter for any mechanical purpose. workflow engine territory per architecture §1.1.
+- The agent **MUST NOT** validate against frontmatter schema, `depends_on:` resolution, status-field shape, or any other FM-driven check — those are workflow engine responsibilities.
+- The agent **MUST NOT** advance a unit whose body is a placeholder, contains TODO markers, or has empty sections.
+- The agent **MUST NOT** reject for stylistic preferences. Substantive gaps only.
+- The agent **MUST** name a specific failed criterion in any rejection.
+- The agent **MUST NOT** invent rules not in this mandate. Stage scope is the contract.
+
+## What you check (BODY ONLY)
+
+### 1. Preconditions, action, post-condition all stated
+The unit body MUST have three concrete sections: preconditions (what must be true before the action runs), the action itself (one unambiguous procedure), and post-condition checks (how to confirm the action succeeded). Reject if any of the three is missing or vague.
+
+### 2. Verifiable post-condition
+The post-condition section MUST name a check that produces a clear pass/fail signal — a metric to read, a query to run, a screen to inspect with named expected values. "Verify by eye that things look good" is a reject.
+
+### 3. Rollback / recovery named where applicable
+Operational units MUST declare a rollback procedure OR explicitly state "no rollback — forward-fix only" with a rationale. Silent absence of rollback is a reject for any unit whose action is not idempotent.
+
+### 4. Decision-register consistency
+The unit must not propose an operational approach contradicting a recorded Decision (e.g., blue-green deploy when Decision N chose canary). Cite the Decision ID.
+
+### 5. Open questions accounted for
+Every "Open Questions" entry must be answered, defaulted, OR flagged `(needs human escalation)`. Operational open questions left to runtime are how outages happen.

package/studios/vendor-management/stages/onboard/outputs/ONBOARDING-CHECKLIST.md

@@ -0,0 +1,25 @@
+---
+name: onboarding-checklist
+location: .haiku/intents/{intent-slug}/stages/onboard/artifacts/
+scope: intent
+format: text
+required: true
+---
+
+# Onboarding Checklist
+
+Vendor integration record with setup verification and escalation paths.
+
+## Expected Artifacts
+
+- **Setup verification** -- account setup, access provisioning, and data migration confirmed complete
+- **Integration validation** -- end-to-end data flow testing with error handling verification
+- **Escalation paths** -- named contacts, response time expectations, and severity definitions
+- **Stakeholder access** -- all stakeholders have necessary access and training confirmed
+
+## Quality Signals
+
+- All setup tasks are confirmed complete with verification evidence
+- Integration is validated end-to-end with error handling tested
+- Escalation paths have named contacts and response time expectations
+- Data flows correctly between systems as verified by integration testing

package/studios/vendor-management/stages/onboard/phases/ELABORATION.md

@@ -0,0 +1,16 @@
+# Onboard Stage — Elaboration
+
+## Criteria Guidance
+
+### Good criteria — concrete and verifiable
+
+- "Onboarding checklist confirms account setup, access provisioning, data migration, and integration testing are complete"
+- "Integration validation includes end-to-end data flow testing with error handling verification"
+- "Escalation paths are documented with named contacts, response time expectations, and severity definitions"
+
+### Bad criteria — vague (no clear check)
+
+- "Vendor is onboarded"
+- "Setup is complete"
+- "Integration works"
+

package/studios/vendor-management/stages/onboard/review-agents/readiness.md

@@ -0,0 +1,10 @@
+---
+interpretation: lens
+---
+**Mandate:** The agent **MUST** verify vendor integration is complete and the organization is ready for operational use.
+
+**Check:**
+- The agent **MUST** verify that end-to-end data flows are tested including error handling scenarios
+- The agent **MUST** verify that all users have appropriate access and training
+- The agent **MUST** verify that escalation paths are documented with named contacts and response expectations
+- The agent **MUST** verify that integration documentation is sufficient for ongoing operational support

package/studios/vendor-management/stages/requirements/STAGE.md

@@ -0,0 +1,13 @@
+---
+name: requirements
+description: Define procurement needs and create RFP
+hats: [analyst, specifier, verifier]
+fix_hats: [analyst, feedback-assessor]
+review: ask
+elaboration: collaborative
+inputs: []
+---
+
+# Requirements
+
+Define procurement needs and create RFP.

package/studios/vendor-management/stages/requirements/discovery/RFP-DOCUMENT.md

@@ -0,0 +1,29 @@
+---
+name: rfp-document
+location: .haiku/intents/{intent-slug}/knowledge/RFP-DOCUMENT.md
+scope: intent
+format: text
+required: true
+---
+
+# RFP Document
+
+Request for proposal with categorized requirements, evaluation criteria, and submission guidelines.
+
+## Content Guide
+
+Structure the RFP for clear, comparable vendor responses:
+
+- **Business context** -- what the organization needs and why
+- **Requirements** -- categorized as mandatory, preferred, and nice-to-have with business justification
+- **Technical specifications** -- integration, performance, data, and security requirements
+- **Evaluation criteria** -- weighted scoring methodology defined before vendor contact
+- **SLA expectations** -- measurable thresholds for availability, performance, and support
+- **Submission guidelines** -- response format, timeline, and evaluation process
+
+## Quality Signals
+
+- Requirements are specific enough to enable objective vendor comparison
+- Evaluation criteria and weights are defined before receiving vendor responses
+- Technical specifications include integration and data handling requirements
+- The RFP is structured to enable apples-to-apples comparison

package/studios/vendor-management/stages/requirements/hats/analyst.md

@@ -0,0 +1,13 @@
+**Focus:** Analyze business needs and translate them into structured procurement requirements.
+
+**Responsibilities:**
+- Document business needs with stakeholder input and validation
+- Categorize requirements by priority (mandatory, preferred, nice-to-have)
+- Identify integration requirements with existing systems and processes
+- Benchmark requirements against market capabilities to ensure feasibility
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** gather requirements from a single stakeholder without cross-functional input
+- The agent **MUST NOT** list features without connecting them to business needs
+- The agent **MUST NOT** set requirements that no vendor in the market can reasonably meet
+- The agent **MUST** distinguish between mandatory requirements and preferences

package/studios/vendor-management/stages/requirements/hats/feedback-assessor.md

@@ -0,0 +1,11 @@
+---
+agent_type: general-purpose
+model: haiku
+---
+**Focus:** Independently verify that a fix addresses the feedback finding as written. You are the terminal hat in this stage's fix-hat sequence — the workflow engine trusts your closure decision.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** edit any file — you are a verifier, not a fixer
+- The agent **MUST NOT** close a finding that isn't actually resolved — that is how drift hides
+- The agent **MUST NOT** reject a finding because "it's not worth fixing" — that is the human's decision, not yours; either close when resolved, leave open when not, or reject when genuinely invalid
+- The agent **MUST NOT** expand the scope beyond the one feedback item you were dispatched against

package/studios/vendor-management/stages/requirements/hats/specifier.md

@@ -0,0 +1,13 @@
+**Focus:** Create detailed technical specifications and the RFP document with evaluation criteria.
+
+**Responsibilities:**
+- Write precise technical specifications for integration, performance, and data requirements
+- Define evaluation criteria with scoring methodology before vendor contact
+- Structure the RFP for clear, comparable vendor responses
+- Include SLA expectations, compliance requirements, and contractual constraints
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** write vague specifications that allow vendors to claim compliance without substance
+- The agent **MUST NOT** define evaluation criteria after receiving vendor responses
+- The agent **MUST NOT** create an RFP that is so complex it discourages qualified vendors from responding
+- The agent **MUST** include data handling, security, and compliance requirements