adoption: run an independent design-partner validation sprint #2603

Goal

Validate Base with independent, permissioned design partners so January claims are not based only on maintainer-owned pilots and first-party demos.

Background

bankbuddy and blend are valuable internal dogfood projects, but both are maintained by the Base owner. They can prove that Base works in its own ecosystem; they cannot establish independent adoption, transferability, or support load. Base's public documentation already distinguishes reference-consumer evidence from independent-adopter evidence.

Tracking: #2555. The work should begin after the v1.13 pilot workflow is stable and should feed #2595.

Scope

• Recruit two or three permissioned external projects representing a single-repository Python project, a multi-repository workspace, and a Bash-heavy operational project where available.
• Validate the documented install, check/doctor, trust, handoff, upgrade, and issue/PR workflow without maintainer-only shortcuts.
• Measure setup time, first successful check, upgrade friction, handoff usefulness, support questions, and recurring failures.
• Record only redacted aggregate evidence and file actionable dogfood-friction issues without exposing private source or secrets.
• Publish a limitations section distinguishing internal pilots, reference consumers, and independent adopters.

Acceptance Criteria

• At least two independent projects complete a permissioned validation path, or the shortfall and reason are documented.
• Each project has a redacted validation record with the same measures and evidence IDs.
• Friction findings are triaged weekly and linked to the owning issue or explicit Future decision.
• docs+test: January readiness scorecard - every public claim mapped to evidence #2595 does not claim independent adoption unless the evidence threshold is met.

Validation

Use the documented adopter validation record, verified matrix evidence from #2601 where applicable, and a redacted friction summary.

Non-Goals

• Do not require external projects to publish proprietary code or data.
• Do not change Base behavior solely for one unvalidated project.
• Do not present permissioned design-partner evidence as broad market adoption.

Project Fields

• Status: Backlog
• Priority: P1
• Area: Product
• Initiative: Adoption Polish
• Size: M
• Milestone: v1.13.0
• Category: enhancement

Agent Assignment

Assignee: codeforester. Maintainer-led coordination and evidence review; do not assign external project changes to an agent.

Plan revision (2026-10-16)

This issue is the independent-adopter gate for #2555 and must feed #2595. At least two permissioned projects that are not maintained as Base reference projects should attempt the documented setup/check/upgrade/handoff path, with redacted evidence and a short support/friction log. If two projects cannot be recruited in the release window, the scorecard must record that shortfall and must not claim independent adoption. No adopter may be exposed to automatic merge/release behavior; the sprint validates product usability and supportability only.