whiteport-design-studio 0.1.0

package/src/workflows/1-project-brief/alignment-signoff/substeps/05-build-contract/24-build-section-03-scope-of-work.md

@@ -0,0 +1,46 @@
+# Substep 24: Build Section 3 - Scope of Work
+
+**Purpose**: Build the Scope of Work section with IN scope, OUT of scope, and deliverables
+
+---
+
+## Instruction
+
+**Section 3: Scope of Work**
+
+**Background**: Defines exactly what will be delivered and what won't be
+
+**What it does**: Lists path forward, deliverables, explicit IN scope, and explicit OUT of scope
+
+**Purpose**: Prevents scope creep and sets clear boundaries - critical for avoiding disputes
+
+**Why this matters**:
+- Most contract disputes arise from unclear scope
+- Clear IN/OUT scope prevents misunderstandings
+- Protects both parties from scope creep
+- Sets expectations upfront
+
+**Content to gather**:
+1. **The Path Forward**: Pull from alignment document (path_forward) - how the work will be done
+2. **Deliverables**: Pull from alignment document (deliverables_list) - what will be delivered
+3. **IN Scope**: Ask user explicitly - "What work is explicitly included? Be specific about what's covered."
+4. **OUT of Scope**: Ask user explicitly - "What work is explicitly NOT included? What would require a change order?"
+
+**Important**: Based on business model, adapt scope section:
+- **Fixed-Price**: Must have very clear IN scope and OUT of scope (critical for fixed-price - this protects both parties)
+- **Hourly**: Can be more flexible, but still define boundaries to prevent misunderstandings
+- **Retainer**: Define what types of work are included in retainer vs. project work
+- **Hybrid**: Define scope for each component separately
+
+**What to ask user**:
+- "Let's be very clear about what's included and what's not. What work is explicitly IN scope for this contract?"
+- "What work is explicitly OUT of scope? What would require a change order?"
+- "Are there any assumptions about what's included that we should document?"
+
+---
+
+## Next Step
+
+After building Scope of Work section:
+→ `25-build-section-04-payment-terms.md` (same folder)
+

package/src/workflows/1-project-brief/alignment-signoff/substeps/05-build-contract/25-build-section-04-payment-terms.md

@@ -0,0 +1,81 @@
+# Substep 25: Build Section 4 - Our Commitment & Payment Terms
+
+**Purpose**: Build payment terms section tailored to business model
+
+---
+
+## Instruction
+
+**Section 4: Our Commitment & Payment Terms**
+
+**Background**: Financial commitment needed and payment structure - tailored to business model
+
+**What it does**: States costs, payment schedule, and payment terms based on selected business model
+
+**Purpose**: Clear financial expectations - transparency builds trust
+
+**Why this matters**: 
+- Protects supplier from non-payment risk
+- Ensures client commits financially to the project
+- Provides cash flow for supplier to deliver quality work
+- Prevents disputes about payment timing
+
+**Adapt based on business model**:
+
+**If Fixed-Price Project**:
+- **User options for payment structure**:
+  - **Upfront payment** (recommended):
+    - **50% upfront, 50% on completion**: Fair split, supplier gets commitment, client retains leverage
+    - **100% upfront**: Full commitment, supplier assumes all risk, client gets best price
+    - **30% upfront, 70% on completion**: Lower upfront, more risk for supplier
+  - **Milestone payments**: Payments tied to specific deliverables or project phases
+  - **Payment on completion**: All payment at end (risky for supplier, not recommended)
+- **Why upfront payment is fair**:
+  - **Supplier assumes risk**: In fixed-price contracts, supplier commits to deliver for a set price regardless of actual costs
+  - **Cost overruns are supplier's problem**: If work takes longer or costs more, supplier absorbs the loss
+  - **Client gets price certainty**: Client knows exact cost upfront
+  - **Upfront payment shows commitment**: Demonstrates client is serious about the project
+  - **Enables quality delivery**: Supplier can invest in resources, tools, and team needed to deliver
+- **What to ask user**:
+  - "For fixed-price contracts, upfront payment is fair since you're assuming the risk. Would you like 50% upfront and 50% on completion, or 100% upfront?"
+  - "Upfront payment protects both parties - you show commitment, and I can deliver quality work without cash flow worries."
+- **Content**: Total project price, payment schedule, payment method, due dates, late payment terms
+
+**If Hourly/Time-Based**:
+- **Payment structure**:
+  - **Billing frequency**: {{billing_frequency}} (e.g., weekly, bi-weekly, monthly)
+  - **Payment terms**: {{payment_terms}} (e.g., Net 15, Net 30)
+  - **Time tracking**: {{time_tracking_method}} (detailed timesheets required)
+  - **Invoice format**: {{invoice_format}} (itemized by date, hours, description)
+- **What to ask user**:
+  - "How often would you like to be invoiced? Weekly, bi-weekly, or monthly?"
+  - "What payment terms work for you? Net 15 or Net 30?"
+- **Content**: Hourly rate, billing frequency, payment terms, time tracking requirements
+
+**If Retainer**:
+- **Payment structure**:
+  - **Monthly retainer**: {{monthly_retainer_amount}} due {{retainer_due_date}} (e.g., "on the 1st of each month")
+  - **Minimum hours**: {{minimum_hours_per_month}} hours included
+  - **Overage billing**: {{overage_billing}} (e.g., "billed monthly for hours beyond minimum")
+  - **Hour rollover**: {{hour_rollover_policy}}
+- **What to ask user**:
+  - "When should the retainer be due each month? (e.g., 1st of the month)"
+  - "How should we handle unused hours? Do they expire or can some roll over?"
+  - "How should overage hours be billed? Monthly or as they occur?"
+- **Content**: Monthly retainer amount, due date, minimum hours, overage rate, rollover policy
+
+**If Hybrid**:
+- **Payment structure**: Combine payment terms from each component
+- **Content**: Payment terms for each component clearly separated
+
+**Content**: Pull from alignment document (our_commitment), add payment schedule and terms based on business model
+
+**Fairness note**: Tailor to business model - for fixed-price emphasize upfront payment fairness, for retainer emphasize commitment and availability
+
+---
+
+## Next Step
+
+After building payment terms:
+→ `26-build-section-05-timeline.md` (same folder)
+

package/src/workflows/1-project-brief/alignment-signoff/substeps/05-build-contract/26-build-section-05-timeline.md

@@ -0,0 +1,31 @@
+# Substep 26: Build Section 5 - Timeline
+
+**Purpose**: Build the Timeline section
+
+---
+
+## Instruction
+
+**Section 5: Timeline**
+
+**Background**: When work will happen
+
+**What it does**: Defines schedule and milestones
+
+**Purpose**: Sets expectations for delivery dates
+
+**Content**: Extract from Work Plan or Investment Required from alignment document
+
+**What to include**:
+- Key milestones
+- Delivery dates
+- Critical deadlines
+
+---
+
+## Next Step
+
+After building Timeline:
+→ `27-build-section-06-availability.md` (same folder - if Retainer model)
+→ `28-build-section-07-confidentiality.md` (same folder - if not Retainer)
+

package/src/workflows/1-project-brief/alignment-signoff/substeps/05-build-contract/27-build-section-06-availability.md

@@ -0,0 +1,38 @@
+# Substep 27: Build Section 6 - Availability (Retainer Only)
+
+**Purpose**: Build Availability section for retainer contracts
+
+---
+
+## Instruction
+
+**Section 6: Availability** (Only for Retainer model)
+
+**Background**: Defines when contractor is available for retainer work
+
+**What it does**: Sets expectations for response times, working hours, availability windows
+
+**Purpose**: Ensures client knows when they can expect work to be done
+
+**Why this matters**:
+- Retainer clients need to know when contractor is available
+- Sets realistic expectations for response times
+- Prevents misunderstandings about availability
+
+**What to include**:
+- **Business hours**: {{business_hours}} (e.g., "Monday-Friday, 9am-5pm EST")
+- **Response time**: {{response_time}} (e.g., "2-3 business days for non-urgent requests")
+- **Availability for meetings**: {{meeting_availability}} (e.g., "Available for scheduled calls during business hours")
+- **Urgent requests**: {{urgent_request_policy}} (e.g., "Urgent requests may incur additional fees")
+
+**What to ask user**: "What availability expectations do you have? What response times work for you?"
+
+**Content**: Define availability expectations based on retainer agreement
+
+---
+
+## Next Step
+
+After building Availability (if applicable):
+→ `28-build-section-07-confidentiality.md` (same folder)
+

package/src/workflows/1-project-brief/alignment-signoff/substeps/05-build-contract/28-build-section-07-confidentiality.md

@@ -0,0 +1,42 @@
+# Substep 28: Build Section 7 - Confidentiality Clause
+
+**Purpose**: Build the Confidentiality clause
+
+---
+
+## Instruction
+
+**Section 7: Confidentiality Clause**
+
+**Background**: Protects sensitive information shared during the project
+
+**What it does**: Requires both parties to keep project information confidential
+
+**Purpose**: Protects proprietary information, business strategies, and trade secrets - mutual protection builds trust
+
+**Why this matters**: 
+- Without this clause, either party could share sensitive project details with competitors
+- Protects your business secrets, customer data, and strategic plans
+- Builds trust by showing mutual respect for confidentiality
+- Prevents legal disputes about information sharing
+
+**User options**:
+- **Standard confidentiality** (recommended): Both parties keep all project information confidential
+- **Limited confidentiality**: Only specific information types are confidential (e.g., financial data only)
+- **One-way confidentiality**: Only one party is bound (rare, usually for public projects)
+- **Duration**: How long confidentiality lasts (typically 2-5 years, or indefinitely for trade secrets)
+- **Exceptions**: What's NOT confidential (public info, independently developed, required by law)
+
+**What to ask user**: "Do you have sensitive information that needs protection? How long should confidentiality last? (Typically 2-5 years)"
+
+**Content**: Standard confidentiality language (see template), customized based on user choices
+
+**Fairness note**: "This protects both parties equally - your sensitive info stays private, and I'm protected too"
+
+---
+
+## Next Step
+
+After building Confidentiality:
+→ `29-build-section-08-not-to-exceed.md` (same folder)
+

package/src/workflows/1-project-brief/alignment-signoff/substeps/05-build-contract/29-build-section-08-not-to-exceed.md

@@ -0,0 +1,54 @@
+# Substep 29: Build Section 8 - Not to Exceed Clause (Conditional)
+
+**Purpose**: Build Not-to-Exceed clause based on business model
+
+---
+
+## Instruction
+
+**Section 8: Not to Exceed Clause** (Conditional - applies to Fixed-Price and optionally Hourly)
+
+**Background**: Sets maximum budget cap - only applies to certain business models
+
+**What it does**: States that costs will not exceed a specified amount without approval
+
+**Purpose**: 
+- Protects both parties from unexpected cost overruns
+- **Prevents scope creep** - Any work beyond original scope requires approval
+- Fair budget protection for everyone
+
+**When this section applies**:
+- **Fixed-Price Project**: ✅ REQUIRED - This is the project price cap
+- **Hourly/Time-Based**: ⚠️ OPTIONAL - Can include optional not-to-exceed cap if desired
+- **Retainer**: ❌ NOT APPLICABLE - Retainer already has monthly cap
+- **Hybrid**: ⚠️ CONDITIONAL - May apply to fixed-price components
+
+**If applicable, include**:
+- **Why this matters**:
+  - Without this clause, costs could spiral out of control (fixed-price)
+  - Protects your budget from unexpected expenses
+  - Prevents scope creep by requiring approval for additional work
+  - Ensures contractor gets paid fairly for extra work through change orders
+  - Creates clear boundaries that prevent misunderstandings
+- **User options**:
+  - **Fixed budget cap**: Hard limit that cannot be exceeded without new agreement
+  - **Soft cap with buffer**: Cap with small percentage buffer (e.g., 10%) for minor overruns
+  - **Cap with change order process**: Cap exists, but change orders can adjust it with approval
+- **What to ask user**: 
+  - **For Fixed-Price**: "The not-to-exceed amount is [total_amount]. This protects both parties from cost overruns. Any work beyond the original scope requires a change order."
+  - **For Hourly**: "Would you like to set an optional not-to-exceed cap? This protects your budget while still allowing flexibility."
+- **Content**: 
+  - **Fixed-Price**: Not-to-exceed = total project price
+  - **Hourly**: Optional cap amount if user wants one
+- **Fairness note**: "This protects your budget while ensuring I get paid fairly for additional work if needed through the change order process"
+
+---
+
+## Decision Point
+
+**If section applies**:
+→ `30-build-section-09-work-initiation.md` (same folder)
+
+**If section doesn't apply** (Retainer):
+→ `30-build-section-09-work-initiation.md` (same folder - skip this section)
+

package/src/workflows/1-project-brief/alignment-signoff/substeps/05-build-contract/30-build-section-09-work-initiation.md

@@ -0,0 +1,41 @@
+# Substep 30: Build Section 9 - Work Initiation
+
+**Purpose**: Build the Work Initiation section
+
+---
+
+## Instruction
+
+**Section 9: Work Initiation**
+
+**Background**: Specifies exactly when work can begin
+
+**What it does**: Defines start date or conditions before work begins
+
+**Purpose**: Prevents unauthorized work, establishes timeline, protects both parties
+
+**Why this matters**:
+- Without this clause, work might begin before contract is fully executed
+- Prevents disputes about when work actually started
+- Protects contractor from doing unpaid work
+- Protects client from unauthorized charges
+- Establishes clear timeline expectations
+
+**User options**:
+- **Upon contract signing**: Work begins immediately when both parties sign
+- **Specific date**: Work begins on a set calendar date
+- **After initial payment**: Work begins when first payment/deposit is received
+- **After written notice**: Work begins when client sends written authorization
+- **Conditional start**: Work begins after specific conditions are met (e.g., materials received, approvals obtained)
+
+**What to ask user**: "When should work begin? Options: immediately upon signing, a specific date, after initial payment, or when you give written notice?"
+
+**Content**: Ask user when work should begin, document the chosen option clearly
+
+---
+
+## Next Step
+
+After building Work Initiation:
+→ `31-build-section-10-terms-and-conditions.md` (same folder)
+

package/src/workflows/1-project-brief/alignment-signoff/substeps/05-build-contract/31-build-section-10-terms-and-conditions.md

@@ -0,0 +1,38 @@
+# Substep 31: Build Section 10 - Terms and Conditions
+
+**Purpose**: Build the Terms and Conditions section
+
+---
+
+## Instruction
+
+**Section 10: Terms and Conditions**
+
+**Background**: Legal framework for the agreement
+
+**What it does**: Covers changes, termination, IP ownership, dispute resolution, jurisdiction
+
+**Purpose**: Protects both parties legally
+
+**Key sections to include**:
+- **Changes and Modifications**: How scope changes are handled (change orders)
+- **Termination**: How to exit the contract (fair notice, payment for work done)
+- **Intellectual Property**: Who owns what (usually client owns deliverables upon payment)
+- **Dispute Resolution**: How conflicts are handled (mediation/arbitration/litigation)
+- **Governing Law and Jurisdiction**: Which laws apply and where legal proceedings take place
+- **Contract Language**: Language of the contract
+
+**Content**: Standard terms including governing law and jurisdiction (see template)
+
+**What to ask user**: 
+- "Which jurisdiction's laws should govern this contract? (e.g., 'State of California, USA', 'England and Wales')"
+- "What language should this contract be in? (e.g., English, Spanish, French)"
+- "If the contract is translated, which version should be the official one?"
+
+---
+
+## Next Step
+
+After building Terms and Conditions:
+→ `32-build-section-11-approval.md` (same folder)
+

package/src/workflows/1-project-brief/alignment-signoff/substeps/05-build-contract/32-build-section-11-approval.md

@@ -0,0 +1,36 @@
+# Substep 32: Build Section 11 - Approval
+
+**Purpose**: Build the Approval section with signature lines
+
+---
+
+## Instruction
+
+**Section 11: Approval**
+
+**Background**: Formal signoff
+
+**What it does**: Signature lines for both parties
+
+**Purpose**: Makes the contract legally binding
+
+**Content**: 
+- Client and contractor names
+- Signature lines
+- Date fields
+
+**For Project Contract**:
+- Client signature
+- Contractor signature
+
+**For Service Agreement**:
+- Client/Owner signature
+- Service Provider signature
+
+---
+
+## Next Step
+
+After building Approval section:
+→ `33-finalize-contract.md` (same folder)
+

package/src/workflows/1-project-brief/alignment-signoff/substeps/05-build-contract/33-finalize-contract.md

@@ -0,0 +1,40 @@
+# Substep 33: Finalize Contract
+
+**Purpose**: Finalize the contract document and present it
+
+---
+
+## Instruction
+
+**After building all sections**:
+
+1. **Review the contract**: "I've built your contract section by section. Let me review it with you..."
+
+2. **Present the contract**: "Your contract is ready at `docs/1-project-brief/contract.md` (or `service-agreement.md`)."
+
+3. **Explain next steps**:
+   - "Review the contract thoroughly"
+   - "Both parties should sign before work begins"
+   - "Once signed, we can proceed to the Project Brief workflow"
+
+4. **Ask**: "Does everything look good? Any adjustments needed before signing?"
+
+---
+
+## After Contract is Signed
+
+**Once contract is signed**:
+- ✅ Alignment achieved
+- ✅ Commitment secured
+- ✅ Legal protection in place
+- ✅ Ready to proceed to Project Brief
+
+**Next**: Full Project Brief workflow
+→ `src/modules/wds/workflows/1-project-brief/project-brief/complete/workflow.md`
+
+---
+
+## State Update
+
+Update frontmatter of contract file with completion status.
+

package/src/workflows/1-project-brief/alignment-signoff/substeps/06-build-signoff-internal/34-build-internal-signoff.md

@@ -0,0 +1,65 @@
+# Substep 34: Build Internal Signoff Document
+
+**Purpose**: Build internal signoff document (alternative to external contract)
+
+---
+
+## Instruction
+
+**For Internal Signoff Document**:
+
+**Focus areas** (not detailed scope/hours):
+- Goals and success metrics
+- Budget estimates
+- Ownership and responsibility
+- Approval workflow
+- Timeline and milestones
+
+**Section 1: Project Overview**
+- The Realization
+- Recommended Solution
+
+**Section 2: Goals and Success Metrics**
+- What we're trying to accomplish
+- Success metrics
+- How we'll measure success
+- Key performance indicators (KPIs)
+
+**Section 3: Budget and Resources**
+- Budget allocation (total budget estimate)
+- Budget breakdown (if applicable)
+- Resources needed (high-level)
+- Not-to-exceed budget cap (if applicable)
+
+**Section 4: Ownership and Responsibility**
+- Project Owner
+- Process Owner
+- Key Stakeholders
+- Decision-Making Authority
+
+**Section 5: Approval and Sign-Off**
+- Who needs to approve
+- Approval stages
+- Sign-off process
+- Timeline for approval
+
+**Section 6: Timeline and Milestones**
+- Key milestones
+- Delivery dates
+- Critical deadlines
+
+**Section 7: Optional Sections**
+- Risks and considerations (optional)
+- Confidentiality (optional)
+- The Path Forward (optional - high-level overview)
+
+**Company Signoff Format (Optional)**:
+- If user has existing company format, ask: "Do you have an existing company signoff document format? You can upload it and I'll adapt it to match your format."
+
+---
+
+## Next Step
+
+After building internal signoff document:
+→ `35-finalize-signoff.md` (same folder)
+

package/src/workflows/1-project-brief/alignment-signoff/substeps/06-build-signoff-internal/35-finalize-signoff.md

@@ -0,0 +1,39 @@
+# Substep 35: Finalize Signoff Document
+
+**Purpose**: Finalize the signoff document and present it
+
+---
+
+## Instruction
+
+**After building the signoff document**:
+
+1. **Present the signoff**: "Your signoff document is ready at `docs/1-project-brief/signoff.md`."
+
+2. **Explain next steps**:
+   - "Share with stakeholders for approval"
+   - "Follow your company's approval workflow"
+   - "Get all required signatures"
+   - "Once approved, we can proceed to the Project Brief workflow"
+
+3. **Ask**: "Does everything look good? Any adjustments needed before seeking approval?"
+
+---
+
+## After Signoff Document is Approved
+
+**Once signoff document is approved**:
+- ✅ Internal alignment achieved
+- ✅ Budget/resources committed
+- ✅ Stakeholders on board
+- ✅ Ready to proceed to Project Brief
+
+**Next**: Full Project Brief workflow
+→ `src/modules/wds/workflows/1-project-brief/project-brief/complete/workflow.md`
+
+---
+
+## State Update
+
+Update frontmatter of signoff file with completion status.
+

package/src/workflows/1-project-brief/alignment-signoff/substeps/substeps-guide.md

@@ -0,0 +1,81 @@
+# Alignment & Signoff Substeps
+
+**Purpose**: Small, sequential instruction files for the Alignment & Signoff workflow
+
+---
+
+## Overview
+
+These substeps break down the Alignment & Signoff workflow into small, focused steps that agents can follow sequentially. Each substep file contains a single, clear action.
+
+---
+
+## Instruction Flow
+
+### Phase 1: Start & Understand (`01-start-understand/`)
+1. `01-understand-situation.md` - Clarify user's situation
+2. `02-determine-if-needed.md` - Determine if alignment & signoff is needed
+3. `03-offer-extract-communications.md` - Offer to extract from communications
+4. `04-extract-info.md` - Extract information (if provided)
+5. `05-detect-starting-point.md` - Detect where user wants to start
+
+### Phase 2: Explore Sections (`02-explore-sections/`) - Flexible Order
+6. `06-explore-realization.md` - Explore The Realization
+7. `07-explore-solution.md` - Explore Solution (if starting with solution)
+8. `08-explore-why-it-matters.md` - Explore Why It Matters
+9. `09-explore-how-we-see-it-working.md` - Explore How We See It Working
+10. `10-explore-paths-we-explored.md` - Explore Paths We Explored
+11. `11-explore-recommended-solution.md` - Explore Recommended Solution
+12. `12-explore-path-forward.md` - Explore The Path Forward
+13. `13-explore-value-we-create.md` - Explore The Value We'll Create
+14. `14-explore-cost-of-inaction.md` - Explore Cost of Inaction
+15. `15-explore-our-commitment.md` - Explore Our Commitment
+16. `16-explore-summary.md` - Explore Summary
+
+### Phase 3: Synthesize & Present (`03-synthesize-present/`)
+17. `17-reflect-back.md` - Reflect back what you've captured
+18. `18-synthesize-document.md` - Synthesize into alignment document
+19. `19-present-for-approval.md` - Present for stakeholder approval
+
+### Phase 4: Generate Signoff (`04-generate-signoff/`) - After Acceptance
+20. `20-offer-signoff-document.md` - Offer to generate signoff document
+21. `21-determine-business-model.md` - Determine business model (external contracts)
+
+### Phase 5: Build External Contract (`05-build-contract/`) - If Selected
+22. `22-build-section-01-project-overview.md` - Build Project Overview
+23. `23-build-section-02-business-model.md` - Build Business Model
+24. `24-build-section-03-scope-of-work.md` - Build Scope of Work (IN/OUT scope)
+25. `25-build-section-04-payment-terms.md` - Build Payment Terms
+26. `26-build-section-05-timeline.md` - Build Timeline
+27. `27-build-section-06-availability.md` - Build Availability (Retainer only)
+28. `28-build-section-07-confidentiality.md` - Build Confidentiality
+29. `29-build-section-08-not-to-exceed.md` - Build Not-to-Exceed (Conditional)
+30. `30-build-section-09-work-initiation.md` - Build Work Initiation
+31. `31-build-section-10-terms-and-conditions.md` - Build Terms and Conditions
+32. `32-build-section-11-approval.md` - Build Approval
+33. `33-finalize-contract.md` - Finalize contract
+
+### Phase 6: Build Internal Signoff (`06-build-signoff-internal/`) - If Selected
+34. `34-build-internal-signoff.md` - Build Internal Signoff Document
+35. `35-finalize-signoff.md` - Finalize signoff document
+
+---
+
+## Usage
+
+**For agents**: Follow these substeps sequentially. Each file contains a single, focused instruction with clear next steps.
+
+**Decision points**: Some substeps have decision points that route to different next steps based on user choices.
+
+**Flexible flow**: Section exploration (substeps 06-16) can be done in any order based on user's natural thinking flow.
+
+---
+
+## Key Principles
+
+- **One instruction per file**: Each substep focuses on a single action
+- **Clear next steps**: Each file specifies what comes next
+- **Decision points**: Route to different paths based on user choices
+- **Reference larger guides**: Substeps reference section-guide.md for detailed guidance
+- **Linear flow**: Follow sequentially, but allow flexibility in section exploration order
+