• Version: 1.0
• Status: Approved
• Date: August 27, 2026
• Upstream baseline observed during preflight: camptocamp/ogc-client@305e3da2cf86cfda5c3254a0be419db70cce54b0
• Workbench branch: OS4CSAPI/ogc-client-CSAPI_2:phase-10
• Delivery branch: OS4CSAPI/ogc-client:clean-pr
• Upstream contribution: camptocamp/ogc-client#136

PR #136 adds OGC API — Connected Systems (CSAPI) support to camptocamp/ogc-client. The contribution remains open and currently uses OS4CSAPI/ogc-client:clean-pr as its head branch.

The CSAPI contribution was last delivered at the end of Phase 8 on April 29, 2026. Phase 9 subsequently synchronized the workbench through upstream PR #140 and produced research and live-testing records, but it did not create a new CSAPI implementation workstream or update the delivery branch.

Canonical upstream has continued to evolve. At the Phase 10 preflight on August 27, 2026:

• workbench phase-9 and the new phase-10 branch shared upstream commit afd9c266cb124c622439677cf438904b7ef1e03f as their latest integrated upstream baseline;
• current upstream/main was 305e3da2cf86cfda5c3254a0be419db70cce54b0;
• 83 commits were reachable from current upstream/main but not from the Phase 9 baseline;
• upstream had added and changed library functionality, dependencies, CI configuration, package entry points, formatting, and the public documentation application;
• upstream had replaced the previous documentation application with VitePress and a TypeDoc-generated API data pipeline;
• upstream had upgraded Prettier from 2.8.8 to the 3.x line;
• delivery clean-pr remained at the squashed Phase 8 commit effaa783ed689187f8d3e3795b4946fa38175448.

The existing CSAPI public documentation also contains stale Phase 6-era examples. In particular, the README still passes an OgcApiEndpoint directly to createCSAPIBuilder() and calls getDataStreams(), while the Phase 8 API uses endpoint.csapi(collectionId), a value-shaped createCSAPIBuilder() factory for advanced consumers, and getDatastreams() naming. These examples must not be carried into the refreshed upstream documentation unchanged.

Phase 10 is therefore a bounded maintenance and integration phase. Its purpose is to bring the already-developed CSAPI contribution forward onto current upstream conventions and restore reviewer-facing accuracy. It is not a new feature-design phase and does not reopen Phase 8 architecture decisions.

Synchronize the existing CSAPI contribution in PR #136 with current camptocamp/ogc-client main, adapt the contribution to the upstream Prettier 3 and VitePress/TypeDoc documentation systems, correct stale public CSAPI documentation and examples, verify the combined library and published package through current automated quality gates, and deliver the accepted result to clean-pr as a minimal, reviewable PR update without expanding CSAPI functionality or reopening settled architecture.

Every Phase 10 acceptance criterion must ultimately map to at least one Roadmap execution unit and an automated or objectively inspectable acceptance gate. The Implementation Guide will define the exact commands after this document is approved.

Phase 10 consists of four bounded workstreams that converge on a single verified update to PR #136.

Bring the existing Phase 8 CSAPI contribution forward across all upstream changes since the Phase 9 baseline. Preserve current upstream behavior, structure, dependencies, package-entry changes, CI expectations, and documentation architecture while resolving only the overlaps necessary to retain CSAPI.

This workstream includes establishing a reproducible upstream baseline and recording merge/conflict evidence. It does not authorize opportunistic refactoring of CSAPI or unrelated upstream code.

Adopt current upstream formatting and runtime expectations across the combined tree. Apply Prettier 3 where required, keep mechanical formatting distinguishable from authored changes, and avoid configuration forks whose only purpose would be to preserve historical Prettier 2 output.

This workstream may include necessary lockfile and configuration resolution caused by synchronization. It does not authorize unrelated dependency upgrades beyond those inherited from the approved upstream baseline or proven necessary for Phase 10 acceptance.

Reconcile the CSAPI public documentation with both the Phase 8 API and upstream's new documentation system:

• restore CSAPI to the supported-standards documentation after upstream synchronization;
• replace stale consumer examples with correct endpoint.csapi(collectionId) and getDatastreams() usage;
• accurately document the advanced, value-shaped createCSAPIBuilder(collection, resourceUrls) API;
• retain subpath imports for CSAPI-specific public symbols;
• include the CSAPI public surface in the VitePress/TypeDoc API reference without bulk-exporting it from the root package entry point;
• update PR #136's reviewer-facing description so it no longer repeats superseded Phase 6 usage.

This is documentation maintenance and integration, not an API redesign or a new documentation-site redesign.

Run the current repository's automated formatter, type, lint, test, documentation, build, and packaging gates under a supported runtime. Resolve only failures attributable to the synchronization or Phase 10 maintenance scope.

After the workbench result is accepted, transfer only the curated contribution-bearing changes to clean-pr, verify workbench/delivery parity over the delivery manifest, update PR #136, and record the final CI evidence.

These decisions are established inputs to Phase 10 and must not be reopened by the Implementation Guide, Roadmap, or individual issues without explicit project-owner approval.

• Synchronization with an explicitly recorded current camptocamp/ogc-client:main baseline.
• Necessary conflict resolution that preserves both current upstream and the existing CSAPI contribution.
• Adoption of upstream Prettier 3 formatting and relevant current toolchain conventions.
• Correction of stale CSAPI README, JSDoc, generated-reference, example, and PR-description content.
• Integration of the CSAPI subpath into upstream's VitePress/TypeDoc documentation pipeline.
• Repository-local tests, fixtures, type checks, lint, documentation build, production build, and package-consumer verification.
• Workbench review, curated clean delivery, tree-parity verification, and PR #136 refresh.

• New CSAPI features, resource types, query helpers, parser capabilities, CRUD behavior, pagination helpers, or result-extraction utilities.
• Reconsideration or redesign of the existing dynamic-import facade.
• Live-server smoke testing or renewed cross-server interoperability research.
• Changes to OpenSensorHub, 52North, CS-Go, or any other independent server or consumer repository.
• Fixes for server-specific nonconformance owned outside this library.
• Unrelated refactors, renames, abstractions, dependency upgrades, or style cleanup.
• Broad redesign of upstream's VitePress site or API-reference user experience.
• Resolution of unrelated defects discovered during Phase 10; such findings are recorded for later disposition.
• Creation of the Implementation Guide, Roadmap, or Phase 10 GitHub issues before their respective approval gates.

Phase 10 verification is layered so that a passing final CI result is supported by narrower evidence:

1. Baseline verification — record exact workbench, delivery, and upstream SHAs and prove the approved upstream commit is integrated.
2. Scope verification — inventory changed files and compare them to the approved Roadmap/delivery manifest.
3. Public-surface verification — compare CSAPI exports and check the root/subpath boundary.
4. Documentation verification — detect obsolete public examples, validate correct import paths, generate TypeDoc data, and build VitePress.
5. Repository QA — run formatting, type checking, lint, Node tests, and browser tests under the supported runtime.
6. Build/package verification — build all targets, inspect the packed artifact, and import both package entry points from a clean consumer context.
7. Delivery verification — compare accepted workbench files with clean-pr, inspect PR metadata, and record GitHub Actions results.

The Implementation Guide must convert these layers into exact commands, expected outputs, failure-handling rules, and a supported runtime specification. The Roadmap must attach the relevant commands to each execution unit rather than postponing all validation until the end.

The descriptive Phase 10 planning and execution workflow records how this document, the later Implementation Guide, Roadmap, and GitHub issues are gated. It does not override this contribution definition.

Phase 10 is complete only when:

• PR #136 is based on an approved current upstream baseline;
• the existing Phase 8 CSAPI API and behavior remain intact;
• the combined tree conforms to upstream's current Prettier and toolchain expectations;
• public CSAPI documentation and examples match the actual API;
• the VitePress/TypeDoc site includes a correct CSAPI subpath API reference;
• repository QA, documentation, production build, and packed-consumer checks satisfy their approved gates;
• the verified workbench result is represented faithfully and minimally on clean-pr;
• PR #136 contains an accurate Phase 10 summary and successful required checks;
• no excluded feature, architecture, server, or unrelated-maintenance work has been absorbed.

At that point, the upstream maintainer can review the refreshed contribution without first resolving new design questions introduced by Phase 10.

The project owner approved this Contribution Goal and Definition on August 27, 2026. Version 1.0 is the authoritative Phase 10 scope contract from which the Implementation Guide must be derived.

Approval authorizes drafting the Implementation Guide only. It does not authorize an upstream merge, source change, formatter migration, Roadmap, GitHub issue, delivery-branch modification, or PR update.