Skip to content

plan: hardcoded policy migration engine#663

Open
github-actions[bot] wants to merge 1 commit into
mainfrom
ci/issue-660
Open

plan: hardcoded policy migration engine#663
github-actions[bot] wants to merge 1 commit into
mainfrom
ci/issue-660

Conversation

@github-actions

Copy link
Copy Markdown
Contributor

Summary

Comprehensive implementation plan for migrating hardcoded policy values into a centralized, validated policy configuration system with adaptive override framework.

Key Points

  • 14 tasks across 5 phases with explicit dependencies
  • 4-level policy precedence chain: learned → user override → repo → hardcoded
  • Failure mode analysis covering 7 critical risks with mitigations
  • Zero breaking changes — backward compatible with fallback behavior
  • Schema validation prevents invalid policies from being applied
  • Incremental adoption — scripts migrate one at a time

What Gets Migrated

  • 25+ hardcoded timeout, threshold, and interval values
  • Policy resolution from 4 sources (learned, user, repo, hardcoded)
  • Model selection escalation/downgrade thresholds
  • Daemon authentication check intervals

Risk Mitigation Highlights

  1. jq failures → fall back to default values
  2. Learned policy corruption → schema validation + atomic writes
  3. Performance → in-memory caching of policy files
  4. Precedence ambiguity → audit logging + policy_debug() command
  5. Race conditions → atomic file operations (atomic mv)
  6. Missing files → graceful degradation to hardcoded defaults
  7. Invalid values → comprehensive validation against JSON Schema

Files Created

  • .claude/IMPLEMENTATION_PLAN.md — Complete 200+ line detailed plan with code examples

Next Steps

  1. Review implementation plan
  2. Approve task decomposition
  3. Begin Phase 1 (Schema & Configuration) when ready

🤖 Generated with Claude Code

Create comprehensive implementation plan for migrating hardcoded policy values
across scripts into a centralized, validated policy configuration system.

Key components:
- Extend config/policy.schema.json with adaptive sections (timeout, model_selection, daemon)
- Centralize 25+ hardcoded values in config/policy.json
- Implement policy_get_with_precedence() with 4-level fallback chain:
  1. ~/.shipwright/learned-policy.json (runtime-learned optimizations)
  2. ~/.shipwright/policy.json (user customizations)
  3. config/policy.json (repo defaults)
  4. hardcoded defaults (final safety fallback)
- Refactor scripts/lib/adaptive-timeout.sh, adaptive-model.sh, daemon-state.sh
- Create sw-policy-migration-test.sh with 15+ test cases
- Document precedence chain and learned policy format in docs/config-policy.md

Failure mode analysis covers 7 critical risks:
- jq command failures with fallback handling
- Race conditions in learned-policy.json rewriting (atomic writes)
- Invalid learned policy injection (schema validation)
- Missing config directory graceful degradation
- Precedence chain ambiguity (audit logging + policy_debug command)
- Performance regression mitigation (in-memory caching)
- Circular dependency and file lock prevention

Task decomposition: 14 tasks across 5 phases
- Phase 1: Schema & Configuration (Tasks 1-3)
- Phase 2: Policy Resolution Engine (Tasks 4-5)
- Phase 3: Script Migration (Tasks 6-8)
- Phase 4: Testing & Validation (Tasks 9-11)
- Phase 5: Documentation & Cleanup (Tasks 12-14)

Definition of Done covers functional requirements, script migration, testing,
documentation, code quality, and evidence verification.

This approach minimizes risk through backward compatibility, incremental adoption,
and comprehensive fallback behavior while enabling runtime policy optimization
via adaptive overrides.

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants