Move hardcoded business-rule thresholds into audited configuration

Why use this

1. A maintainer moving hardcoded thresholds into configuration may preserve the numerical values while changing defaults, units or boundary behavior. Tests can appear to pass if they are weakened or changed to fit the new implementation.

2. A rule-by-rule migration plan could preserve the original behavior baseline and identify where domain-owner approval is needed. It would make proposed configuration changes and future test evidence reviewable without treating structural cleanup as proof of equivalence.

Why an agent / simpler alternative

Useful judgment

Identify related thresholds and trace their business meaning while exposing inconsistent assumptions.

Simpler alternative

Extract a small stable set manually when rules are simple and well covered.

Unsuitable when

Business-rule ownership, default behavior or trusted tests are missing.

Proposed inputs

1. Name

   Threshold inventory

   Owner

   Maintainer

   Minimum scope

   Relevant code locations, values, units and rule references

   Quality check

   Distinguish similar numbers with different business meanings.

2. Name

   Approved behavior/test baseline

   Owner

   Domain and engineering owners

   Minimum scope

   Existing tests, boundary expectations and permitted configuration rules

   Quality check

   Preserve the original test suite and identify separately proposed checks.

Access and setup — proposed or unknown

Proposed minimum

1. Read-only rule/test inspection and an offline configuration/task plan.

Compatibility unknowns

1. Unknown: exact runtime, configuration-loading behavior, test tools and repository access.

External actions requiring approval

1. Creating shared tasks, editing rules/tests, deploying configuration or changing business thresholds.

Expected deliverable and review checks

Proposed artifact

Per-rule configuration mapping and review plan with original-behavior and test-integrity checkpoints.

Critical checks

1. Values, units and comparison boundaries remain explicit.

2. Changed tests cannot substitute for evidence that the original behavior is preserved.

Missing output evidence

No new workflow run or output inspection was performed for this overlay.

Failure signals and proposed responses

1. Signal

   A missing configuration key silently changes the old default.

   Why it matters

   Behavior could differ without an obvious code regression.

   Proposed response

   Require an approved default/failure rule and targeted later verification.

2. Signal

   A boundary test is relaxed to make the migration pass.

   Why it matters

   The evidence no longer protects the original rule.

   Proposed response

   Preserve the baseline and flag the test change for owner review.

Effort and cost — unknown

Setup work

1. Map rule ownership and establish immutable comparison expectations.

Ongoing review

1. Review configuration semantics and actual test evidence separately.

Unknowns

1. Unknown: rule coverage, migration effort and deployment risk.

First check — proposed, unexecuted

Status

proposed_unexecuted

Synthetic fixture

An invented migration plan omits a default and changes a boundary test’s expected result.

Acceptance checks

1. Both issues block equivalence claims.

2. No mutation check or test pass is represented as executed.

Stop conditions

1. Business-rule approval, code changes or test execution is required.

Limits

1. Editorial configuration planning; manifest review is not regression, mutation or business-rule validation.