view release on metacpan or  search on metacpan

doc/internal-operating-checklist.md  view on Meta::CPAN

5. Rerun Scorecard.
6. Repeat until every actionable check is `10 / 10`.
7. If a check cannot reach `10 / 10` because of platform/history/contributor constraints, document the blocker with evidence.

Do not declare completion while repo-fixable Scorecard failures remain.

## 12. New Incoming Work Process

When new work arrives, handle it in this order:

1. Read all relevant instructions and docs fully.
2. Classify the work:
   - bug fix
   - behavior change
   - security change
   - runtime/collector change
   - browser change
   - packaging/release change
   - Windows/bootstrap change
3. Identify affected runtime surfaces and test environments.
4. Check `MISTAKE.md` for known failure patterns in that area.
5. Write or update tests first.
6. Implement the smallest coherent fix.
7. Verify locally.
8. Update docs and metadata.
9. Run the required integration/platform gates.
10. Commit only after the change is actually proven.
11. Push only after verification is complete.

## 13. Project Management Cadence

Treat incoming work as a managed delivery loop, not ad hoc patching.

1. intake:
   classify the work and find the governing docs, tests, and past mistakes
2. scope:
   identify affected surfaces, risks, and required environments
3. proof:
   define the expected result in tests and acceptance terms
4. implementation:
   make the smallest coherent change that satisfies the proof
5. verification:
   run local, browser, integration, packaging, and platform gates required by the scope
6. documentation:
   update user docs, POD, `Changes`, and bug history in the same pass
7. release-readiness:
   build, install, verify, push, then rerun remote gates such as Scorecard
8. learning:
   record mistakes and fix patterns so the same failure mode is easier to catch next time

## 14. Recurring Mistakes To Screen For

Before and after implementation, explicitly check for these repeat failure
patterns:

1. claiming success before the runtime is truly ready
2. reading only part of the instructions or only part of the relevant docs
3. flattening layered behavior into a simpler project-vs-home shortcut
4. allowing docs, POD, or release notes to drift from real behavior
5. relying on source-checkout paths that fail after tarball install
6. weakening auth or exposing browser/runtime data incorrectly
7. trusting test output without checking real browser or SSL/runtime behavior where required
8. under-testing Windows, blank-environment installs, or packaged-runtime paths
9. treating Scorecard, coverage, or packaging as optional cleanup instead of delivery gates
10. stopping at `I can do X next` when X is already the correct next action

## 15. Definition Of Done

A task is done only when:

1. the implementation is correct
2. the required tests prove it
3. the coverage gate still passes
4. the docs and POD match reality
5. the packaging and installability gates are satisfied where required
6. the security and repo checks are clean
7. the relevant platform-specific verification is complete
8. the known mistake patterns for that area were screened and not repeated
9. Scorecard is clean for repo-fixable checks when the task is meant to be fully closed
10. ending with optional "if you want" prompts instead of executing the next justified action already implied by the task or repo rules