bdsqqq/dots/making-meaningful-contributions

making meaningful contributions

a readiness gate for work you intend to hand off. evaluating readiness is read-only; preparation, fixes, commits, pushes, and publication require their respective authorization. this skill does not grant it.

"your job is to deliver code you have proven to work." —

simon willison

apply that standard with bounded evidence: untested behavior is unverified, not necessarily broken. help reviewers understand what was demonstrated and what they would still be accepting on trust.

readiness gate

1. scope: compare the final diff with the requested outcome. identify unrelated

changes, generated artifacts, and affected consumers. preserve others' work; flag scope drift rather than discarding it.

1. behavior: state the input, observable outcome, and failure boundary. select

checks by how the change is consumed, following project verification guidance. distinguish parsing, typechecking, builds, runtime checks, and visual evidence.

1. regression evidence: for a fix, prefer a focused test that fails without the

fix and passes with it. inspect whether its assertion actually detects the reported defect. never revert someone else's working tree to demonstrate this; use an authorized isolated fixture or report that sensitivity is unverified.

1. edges: cover consequential invalid inputs, failures, lifecycle transitions,

or platforms implicated by the change. explain omitted coverage rather than demand every conceivable test or a manual check for every patch.

1. review: use the review procedure for evaluating defects

in the final revision. resolve findings only within authorized scope. when evidence already applies to the unchanged revision, reuse it rather than commission another review merely to satisfy ceremony.

1. handoff: provide the changed behavior and rationale, relevant paths,

commands/results, remaining risks, and any decision needed. keep evidence tied to the final artifact; rerun affected checks after further changes.

readiness decision

• ready within stated scope: relevant checks passed and no known blocking

findings remain. this is not a guarantee beyond the checked behavior.

• blocked: a known defect, failed required check, or missing requirement needs

resolution before submission.

• needs acceptance of a gap: tooling, platform, or evidence is unavailable.

state the missing command/observation and consequence; do not silently mark it passed or assume the reviewer accepts the risk.

stop at the assessment unless further action was requested. avoid repeated polishing loops once the acceptance evidence is sufficient.

contrastive examples

weak handoff: “implemented the cache fix; tests pass.”

bounded handoff: “invalidation now waits for persistence. the delayed-write regression test failed on the old implementation and passes on this revision. typecheck passed. multi-process invalidation was not exercised.”

use that wording only when those checks actually ran.

contract mismatch: naming a value VersionedStructuredRequestWithOptions while accepting unversioned requests hides a boundary from callers. either the name or the accepted contract needs clarification; a longer name alone does not make the contribution ready.

the gate exists to reduce evidence reconstruction for reviewers, not to turn submission into a claim of universal correctness.