diff --git a/.github/workflows/pages.yml b/.github/workflows/pages.yml index 8b0fba65..c8858acb 100644 --- a/.github/workflows/pages.yml +++ b/.github/workflows/pages.yml @@ -30,11 +30,11 @@ jobs: with: enablement: true - - name: Stage runtime files + - name: Stage runtime and documentation files run: | mkdir -p _site/docs cp index.html 404.html app.js cloud-sync.js analytics.js styles.css toast-state.css wbs.json _site/ - cp docs/user-guide.md _site/docs/ + cp docs/index.html docs/user-guide.md docs/api.md docs/deploy.md docs/security.md _site/docs/ - name: Upload static artifact uses: actions/upload-pages-artifact@fc324d3547104276b827a68afc52ff2a11cc49c9 diff --git a/docs/index.html b/docs/index.html new file mode 100644 index 00000000..2cc3bf6b --- /dev/null +++ b/docs/index.html @@ -0,0 +1,66 @@ + + + + + + + ScopeWeave Docs + + + +
+

ScopeWeave

+

Schedule-control WBS planning that works as a standalone static planner and as a Cloud/SaaS workspace over the same planning model.

+ +
+ Open planner + GitHub repository + Releases + Ask DeepWiki +
+ +

Publication truth: this documentation hub describes capabilities present on protected develop. Open pull requests and planned migrations are not shipped product evidence until integrated and revalidated.

+ +

Product responsibility

+

ScopeWeave owns schedule-control planning, WBS hierarchy and editing, deterministic schedule analysis, portable project data, and the optional authenticated cloud collaboration layer. Standalone operation remains a product invariant: cloud capabilities must not make local planning depend on a server, database, credential, or model.

+

Protected develop includes the static planner plus a Node/Hono Cloud/SaaS runtime with account, tenant, collaboration, billing/entitlement, audit, search, integration, and observability surfaces. The current protected persistence profile uses Node SQLite; planned PostgreSQL work is not described here as already shipped.

+ +

Start here

+
+ User guidePlan, edit, analyze, import/export, and use the planner. + API referenceCloud/SaaS endpoints and integration contracts. + Deployment guideRuntime configuration and deployment boundaries. + Security notesAuthentication, tenancy, secrets, and fail-closed expectations. + ArchitectureAs-built authority, trust boundaries, and service composition. + ChangelogProtected product changes and unreleased work classification. +
+ +

Architecture at a glance

+

The static browser planner owns the canonical standalone interaction model. cloud-sync.js adds an optional authenticated cloud overlay. The server layer owns cloud HTTP/API composition, authentication, tenancy, current SQLite persistence, billing boundaries, document integration, bounded attachment refresh, and contextual-orchestrator integration. Cross-service systems are consumed through explicit APIs/adapters rather than shared application databases.

+ +

Onboarding

+

For a no-server evaluation, open the planner on this Pages site or serve the repository with a local static HTTP server. For the Cloud/SaaS profile, install the pinned Node dependencies, provide a durable JWT signing secret, run the server, and follow the deployment guide before exposing the service. Integration consumers should start with the API reference and keep tenant and authorization decisions server-owned.

+ +

Verification and release boundary

+

Repository-native unit/API, browser, coverage, fuzz, dependency, OSV, and security workflows plus organization-required protected checks form the integration evidence. Pending, skipped, cancelled, failed, stale, predecessor-head, or model-only evidence is not equivalent to a passing current revision. Published releases remain distinct from active pull-request behavior.

+ + +
+ +