Adopt-Extend-Compose-Build Decision

These examples and illustrative results are independently authored teaching materials, not measured model results.

Use case

A docs repository needs link checks; its maintained script covers href/fragments but not language destinations. The teaching environment can inspect local code only, with registries unavailable. Choose adopt/extend/compose/build without treating absent channels as no solution anywhere.

Mechanism

Inspect relevant local code/tests and available external channels. Compare interfaces, coverage, maintenance, license and dependency cost. Adopt fitting capability, extend small gaps, compose real complements or build justified missing behavior. Report scope/reasons and review dependencies before execution.

Bad example

Build a duplicate checker without reading maintenance code, declare no existing solutions after a registry failure and add unreviewed packages.

Good example

Inspect the teaching href/fragment checker/tests and verify its language gap. Extend that piece with evidence instead of rebuilding parsing. Unavailable external search means uninspected, not global absence. Record candidates/fit and similarly justify composition/custom work where needed.

Why the change matters

Reuse does not mean always installing a package; visible capability/gaps determine the path. Explicit search boundaries prevent not-seen from becoming nonexistent.

Observable expectation

An illustrative choice extends the existing checker, identifies retained coverage/new language checks/results and marks external search unavailable.

Inspect no duplicate pipeline, fit beyond popularity/license labels and no absence claim for unseen scopes.

Limits

Existing/popular code can be wrong and needs contract checks. Custom work remains valid when justified. Do not exhaust irrelevant channels or universalize source package counts/tool paths.