Samchil documentation will be organized around verification evidence, module contracts, known limitations, and purchase/access boundaries before API details.
01 / Planned
Getting Started
Explain how to evaluate Samchil, read a badge, inspect limitations, and decide whether a module fits a project.
Samchil promise and exclusions
How to read module pages
Where to find Verification Reports
Contact and support paths
Status
Planned
Audience
Technical buyers and first-time module users
Boundary
Does not claim that a badge replaces the buyer's own production validation.
02 / Draft source exists
Samchil Verification Standard
Document Verified, Trusted, and Proven levels with the evidence required for each level.
Evidence philosophy
Badge level requirements
Downgrade and review expectations
Explicit non-guarantees
Status
Draft source exists
Audience
Buyers, maintainers, and reviewers
Boundary
SVS is not legal, regulatory, compliance, or security certification.
03 / Planned
Module Contracts
Describe package contents, version expectations, supported runtime scope, and what buyers receive after access.
Package contents
Runtime and compatibility notes
Known limitations
Update policy references
Status
Planned
Audience
Developers integrating a paid module
Boundary
No module contract should promise custom integration, universal compatibility, or production fitness.
04 / Partially implemented
Verification Reports
Explain report fields, evidence statuses, compatibility rows, limitations, and how badge approval is recorded.
Quality, security, documentation, and compatibility sections
Evidence references
Known critical issue handling
Badge approval caveats
Status
Partially implemented
Audience
Technical evaluators comparing evidence before purchase
Boundary
Reports describe reviewed scope only; they do not prove every environment or future version.
05 / Env and API Error Handler checkout wired
Purchase And Access
Document the purchase path, GitHub Private Repository access model, manual recovery expectations, and open implementation gaps.
Polar hosted checkout
GitHub repository access via connected Polar benefit
Env Config Validator and API Error Handler checkout paths
Manual support path
Website-owned order/webhook gaps
Status
Env and API Error Handler checkout wired
Audience
Buyers using Polar checkout and GitHub repository access
Boundary
Do not imply website-owned license records, webhooks, or refund automation exist before they are implemented.
06 / Draft policy source exists
License, Refunds, And Support
Make allowed use, prohibited redistribution, refund eligibility, and support scope visible before purchase.
Commercial license summary
Refund window and eligibility
Support email and scope
Warranty and certification exclusions
Status
Draft policy source exists
Audience
Buyers reviewing commercial and support boundaries
Boundary
Refund and legal policy wording requires owner/legal review before final publication.
07 / Planned per module
Integration Guides
Provide module-specific installation, configuration, examples, and framework notes from reviewed package evidence.
Install and import steps
Minimal examples
Framework-specific notes only when implemented
Troubleshooting based on documented behavior
Status
Planned per module
Audience
Developers adding a module to their application
Boundary
Do not publish framework guides for examples that do not exist in the module yet.
08 / Planned
Changes And Migration
Track changelog, update policy, compatibility changes, and migration notes for module releases.
Release tags
Compatibility changes
Breaking change notes
Verification report updates
Status
Planned
Audience
Existing buyers evaluating updates
Boundary
Do not promise long-term maintenance or SLA commitments beyond approved package policy.
Publication rule
Public documentation must stay aligned with implemented capability, verified evidence, and owner-reviewed launch boundaries.
Owner review is required before publishing new badge claims, pricing claims, support promises, refund language, or product availability statements.
