Technical pre-review: Sourcey-generated /sourcey/ docs package (Frantic #46 candidate) #11930

Hello Testcontainers maintainers,

I am preparing a sponsored candidate contribution for Frantic #46. No Frantic claim has been made. This is a technical pre-review request for an unclaimed, unmerged, and undeployed proposal; it is not an endorsement, approval, or adoption by Testcontainers.

Exact package proposed for review:

• Pre-review fork repository: https://github.com/fengyangxxx/testcontainers-java
• Planned immutable commit URL: fengyangxxx@c4e1494
• Upstream baseline: deb78e1
• Change set: 58 added files, 1,530,079 bytes, all under docs/sourcey/
• Package tree SHA-256: cf0de3c16a9ef935b861d3f40ed945f06066e7198e017e677ef6f96fa8806e6b
• Intended production URL if later accepted and deployed: https://java.testcontainers.org/sourcey/

The package is a Sourcey-generated static documentation site covering 25 selected high-value Testcontainers Java pages. Placing the generated files under docs/sourcey/ lets the existing MkDocs build copy them to /sourcey/, so the intended home remains Testcontainers' Netlify production deployment with no personal hosting dependency.

The tradeoff is deliberate: committing generated HTML and assets makes deployment deterministic and avoids adding a Sourcey runtime to the official build, but it adds about 1.53 MB and requires regeneration when the pinned source material or presentation changes. Maintenance can remain bounded by reviewing one isolated directory, checking its package hash, and replacing that directory atomically when a refresh is wanted.

Could you technically pre-review this exact immutable package and identify any changes needed for repository fit, content, navigation, licensing, accessibility, or maintenance? No immediate merge is requested, and there is no deadline or urgency for this pre-review.

If the exact package is technically acceptable, would you be willing, at a time you choose, to reserve an approximately 20-minute post-claim synchronous review/merge/deploy window? The later contribution would use the same bytes in a claimant-authored PR based on the stated upstream pin, subject to any changes you request before a claim is made.

A pre-review response does not constitute adoption. Only an actual post-claim merge of the claimant-authored PR, followed by target-owned production deployment of the exact reviewed bytes, would satisfy the adoption boundary.

Suggested reply options:

• Yes: the exact package is suitable for a later post-claim PR, and a review/merge/deploy window can be coordinated at a maintainer-chosen time.
• No: this generated documentation package or publication path is not something the project wants to adopt.
• Changes needed: please list the changes required before you would consider the later PR or reserve a window.