community: define contributor entry points and collect external install reports

[Altairpaca]

Goal

Make DSHelm legible as a community infrastructure project whose contribution paths correspond to reproducible user evidence, not only maintainer architecture work.

The community entry points should now reinforce the two main product proofs in #46/#47: effective runtime route truth and compatibility evidence.

Bounded contribution areas

1. Platform/install evidence

Contribute one reproducible row to #8:

• OS / architecture;
• Node / pnpm / DSH / DSHelm versions;
• install / doctor / first-run / uninstall result;
• redacted exact failure before workarounds.

Existing good-first platform tasks remain the easiest entry point for contributors who do not want to change router internals.

2. Route-truth cases

Contribute a minimal route scenario useful to #46:

• requested/root route;
• child/role route intent when known;
• actual effective provider/model/reasoning evidence when observable;
• whether the difference is an explicit override, fallback, expected policy result, suspected stale state, or unknown;
• no API keys, cookies, private prompts/data, or account identifiers.

A reproducible route-divergence case is more useful than a generic "routing is wrong" report.

3. Compatibility/version-skew fixtures

Contribute evidence useful to #34/#41/#47:

• exact DSH/plugin/package cohort;
• which layer failed: source/API, package resolution, Cordis composition, Web client, Session lifecycle, clean-profile boot, or runtime journey;
• green static checks must be reported separately from real host/runtime evidence.

4. Provider/model evidence

• attach official/runtime source provenance for capability changes;
• keep runtime readiness separate from catalog presence;
• do not translate benchmark/release-note claims directly into routing scores;
• retain unknown/stale states when evidence is incomplete.

5. Documentation/reproducible bugs

Prefer a bounded correction or reproducible fixture over broad feature proposals without evidence.

Contribution guidance to maintain

• Point install reports to the platform evidence template and qa: build a cross-platform community installation evidence matrix #8.
• Point route-divergence reports to the requested/resolved/effective vocabulary from feat: ship Effective Route Inspector and escalation guard #46.
• Point compatibility reports to the layer vocabulary from feat: expose a machine-readable DSH Compatibility Radar #47.
• Document privacy redaction for tokens, cookies, account identifiers, user-home paths, private repository names and private prompt/data content.
• Point DSH public-interface questions back to the relevant upstream Discussion rather than inventing an undocumented parallel contract.
• Link accepted external install/route/compatibility evidence from this issue so it becomes a reusable casebook.

Next community milestone

This issue contributes to the adoption milestone in #23/#32:

• 3 reproducible non-maintainer install reports;
• 2 external routing/use cases or route traces;
• 1 external contributor PR;
• 1 external DSH project/index/integration that cites or consumes a DSHelm route/compatibility contract.

Raw star count is not an acceptance criterion.

Related: #8 #23 #32 #34 #41 #46 #47.

[Altairpaca]

Maintenance update (2026-09): PR #12 establishes the first contributor-funnel layer:

• adds a project Code of Conduct and Support/channel guide;
• routes usage/design questions to DSHelm Discussions and upstream DSH contract questions to DSH Discussions;
• makes non-trivial Core/schema/runtime/provider/compatibility/UI work issue-first;
• changes the PR template to require problem, linked issue, reproducible evidence, and compatibility/policy impact;
• links the community-health guides from both READMEs.

This addresses the entry-path/governance part of this issue. Remaining work should focus on discoverable bounded starter tasks and collecting actual non-maintainer install/routing reports; the issue should stay open until external evidence exists.

[Altairpaca]

Main-branch progress update:

• PR docs: tighten community contribution and support flow #12 is merged: contributor/support funnel, issue-first scope rules, evidence-driven PR template, Code of Conduct, and channel routing are now live.
• PR feat: add credential-free first-run routing example #13 is merged: the root README now exposes a credential-free first-run routing fixture; this provides one reusable observable user case while example: ship a credential-light planner → workers → reviewer first-run path #9 remains open for live bounded execution.
• good first issue: verify source-preview install on macOS Apple Silicon #15 and good first issue: verify source-preview install on Windows 11 + WSL2 #16 are open as bounded good first issue + help wanted platform-verification tasks for macOS Apple Silicon and Windows 11 + WSL2.
• PR chore: prepare publishable package surfaces and release contract #14 is merged: package/release hygiene and CI stale-run cancellation are now on main.

The repository-side entry path is therefore largely in place. Keep #10 open for the community-side success criteria: non-maintainer issues/PRs and linked external install/routing evidence.