@blocklet/payment-react/.aigne/doc-smith/config.yaml

Reusable react components for payment kit v2

# Project information for documentation publishing
projectName: "Payment Kit UI (React)"
projectDesc: "@blocklet/payment-react is a React library for blocklet payment systems with Payment Kit."
projectLogo: https://store.blocklet.dev/assets/z2qaCNvKMv5GjouKdcDWexv6WqtHbpNPQDnAk/logo.png?imageFilter=convert&f=png&w=64

# =============================================================================
# Documentation Configuration
# =============================================================================

# Purpose: What's the main outcome you want readers to achieve?
# Available options (uncomment and modify as needed):
#   getStarted       - Get started quickly: Help new users go from zero to working in <30 minutes
#   completeTasks    - Complete specific tasks: Guide users through common workflows and use cases
#   findAnswers      - Find answers fast: Provide searchable reference for all features and APIs
#   understandSystem - Understand the system: Explain how it works, why design decisions were made
#   solveProblems    - Solve problems: Help users troubleshoot and fix issues
#   mixedPurpose     - Mix of above: Comprehensive documentation covering multiple needs
documentPurpose:
  - getStarted
  - completeTasks

# Target Audience: Who will be reading this most often?
# Available options (uncomment and modify as needed):
#   endUsers         - End users (non-technical): People who use the product but don't code
#   developers       - Developers integrating: Engineers adding this to their projects
#   devops           - DevOps/Infrastructure: Teams deploying, monitoring, maintaining systems
#   decisionMakers   - Technical decision makers: Architects, leads evaluating or planning implementation
#   supportTeams     - Support teams: People helping others use the product
#   mixedTechnical   - Mixed technical audience: Developers, DevOps, and technical users
targetAudienceTypes:
  - developers

# Reader Knowledge Level: What do readers typically know when they arrive?
# Available options (uncomment and modify as needed):
#   completeBeginners    - Complete beginners: New to this domain/technology entirely
#   domainFamiliar       - Domain-familiar, tool-new: Know the problem space, new to this specific solution
#   experiencedUsers     - Experienced users: Regular users needing reference/advanced topics
#   emergencyTroubleshooting - Emergency/troubleshooting: Something's broken, need to fix it quickly
#   exploringEvaluating  - Exploring/evaluating: Trying to understand if this fits their needs
readerKnowledgeLevel: completeBeginners

# Documentation Depth: How comprehensive should the documentation be?
# Available options (uncomment and modify as needed):
#   essentialOnly      - Essential only: Cover the 80% use cases, keep it concise
#   balancedCoverage   - Balanced coverage: Good depth with practical examples [RECOMMENDED]
#   comprehensive      - Comprehensive: Cover all features, edge cases, and advanced scenarios
#   aiDecide           - Let AI decide: Analyze code complexity and suggest appropriate depth
documentationDepth: balancedCoverage

# Custom Rules: Define specific documentation generation rules and requirements
rules: |
  The generated documentation should focus on React component usage, not RFC-style specifications.
  
  ## Documentation Scope
  - **Focus on Key Components Only** - Document only the most important and frequently used components
  - Prioritize core payment flow components over utility components
  
  ## Component Documentation Requirements
  For each React component, document:
  1. **Input Parameters (Props)** - All props with types, descriptions, and required/optional status
  2. **Usage Scenarios** - Different ways to pass parameters for various use cases and their effects
  3. **Implementation-Based Logic** - Strictly follow the actual component implementation to avoid hallucinations
  4. **Integration Examples** - Complete working examples showing proper component integration
  
  ## Provider Integration
  - **PaymentProvider and DonateProvider**: Document how to use these providers and integrate with components
  - **Context Requirements**: Explain which components need to be wrapped by which providers
  - **Example**: If user needs CheckoutForm, document that it must be wrapped with PaymentProvider
  - Show complete integration patterns with provider setup
  
  ## Key Components to Prioritize
  - **Core Payment**: Payment, CheckoutForm, CheckoutDonate, CheckoutTable
  - **Payment Integration**: StripeForm, PaymentSummary
  - **Essential Forms**: AddressForm, CurrencySelector, PhoneInput, CountrySelect
  - **Critical UI**: PricingTable
  - **History Components**: CustomerInvoiceList, CustomerPaymentList, CreditGrantsList, CreditTransactionsList
  - **Business Components**: OverdueInvoicePayment, ResumeSubscription
  - **Utility Components**: SafeGuard
  - **Provider Components**: PaymentProvider, DonateProvider
  - **Price/Amount Utilities**: Key formatting functions from util.ts
  - **Status/Display Utilities**: Status and display formatting functions from util.ts
  
  ## Documentation Structure
  - Component overview and purpose
  - Props interface with detailed explanations
  - Usage scenarios with different prop combinations
  - Integration examples with providers
  - Best practices and common patterns
  
  ## Content Rules
  - Use async/await for asynchronous examples
  - Show complete, runnable code examples
  - Include TypeScript prop interfaces
  - Document provider requirements clearly
  - Base all descriptions on actual component implementation
  
  The documentation process can use tests for examples, but do not generate docs for test files themselves.
# Target Audience: Describe your specific target audience and their characteristics  
targetAudience: |
  Frontend developers integrating payment functionality into React applications.
  Expected to have React/TypeScript experience and basic understanding of payment workflows. 

locale: en
# translateLanguages:  # List of languages to translate the documentation to
#   - zh  # Example: Chinese translation
#   - en  # Example: English translation
docsDir: ./docs  # Directory to save generated documentation
sourcesPath:  # Source code paths to analyze
  - ./src
  - ./README.md
lastGitHead: 142d32cc210fa65a9d3fb87fe42451d924e96f7a
# appUrl: "https://www.staging.arcblock.io/"
appUrl: https://docsmith.aigne.io
boardId: "payment-kit-react"
translateLanguages:
  - zh
  - zh-TW
  - ja
# Checkout ID for document deployment service
checkoutId: ""
# Should sync branding for documentation
shouldSyncBranding: ""