Support project-declared PR workflow policy for Base-managed projects

[codeforester]

Summary

Design future support for Base-managed projects to declare their own GitHub pull request workflow policy, including required PR sections, label-triggered sections, and path-triggered sections.

This is future work. The immediate Base repository policy is tracked separately in #402.

Product direction

Base should provide the workflow mechanism and sensible defaults, but each Base-managed project should own its own PR policy.

Base should not hardcode Base-specific concepts such as Demo Impact into every project. Instead, projects should be able to declare the special PR sections they care about.

Possible manifest shape

github:
  pr:
    template: .github/pull_request_template.md
    required_sections:
      default:
        - Summary
        - Issue
        - Validation
      labels:
        needs-demo:
          - Demo Impact
        security:
          - Security Notes
        breaking-change:
          - Migration Notes
      paths:
        docs/**:
          - Docs Impact
        migrations/**:
          - Migration Plan
          - Rollback Plan
        api/**:
          - API Compatibility

Future behavior

A future basectl gh pr create could:

• Detect the current Base-managed project.
• Read the project's base_manifest.yaml.
• Read linked issue metadata.
• Start from Base's standard PR defaults.
• Add project-specific required sections based on labels and changed paths.
• Generate the PR body.
• Warn or fail when required sections are missing.

Design questions

• Should PR policy live in base_manifest.yaml, .github/base-pr-policy.yaml, or both?
• Should Base validate only the generated body, or also validate manually edited PRs?
• Should missing required sections warn or block?
• How should path-triggered sections work before a PR is opened?
• Should repository-level config override Base defaults or only extend them?
• How much of this should be supported by basectl gh pr create versus GitHub Actions?

Acceptance criteria for future implementation

• Project-specific PR policy is documented.
• Base has a stable schema for default, label-triggered, and path-triggered sections.
• Base's own PR policy can be represented using the same mechanism or a compatible subset.
• The feature does not force Base-specific labels or sections onto other projects.
• Tests cover config parsing and PR body generation behavior.

Out of scope for now

• Implementing this before Base's own PR policy has matured.
• Enforcing policies across all Base-managed projects by default.
• Managing GitHub Project fields for child projects without explicit project configuration.