Problem

OpenSpec 1.14.1 hard-codes MAX_REQUIREMENT_TEXT_LENGTH = 500. Descriptions above that limit produce a warning under normal validation and fail under --strict.

Concise requirements are a useful authoring default, and 500 characters is reasonable for an ADDED requirement being drafted in a change delta. However, the same threshold is also applied to canonical capability specifications, which serve a different purpose.

Canonical requirements are durable behavioral contracts. Over time they may need to preserve interacting authorization, tenancy, security, evidence, recovery, compatibility, and failure-mode invariants. Applying the same authoring threshold can encourage artificial fragmentation or removal of important qualifications.

There is also a lifecycle inconsistency: OpenSpec deliberately does not length-check MODIFIED requirements inside a change, but after such a modification reaches the canonical spec, the resulting requirement can fail strict validation.

This means projects cannot independently adopt strict validation and newer archive-safety improvements without either rewriting accepted canonical specifications or abandoning the strict gate.

Background

The 500-character value was introduced as an informational heuristic in #35. Subsequent work in #1976, #1978, and #2020 carefully documented, tested, and enforced the boundary, but retained the same global hard-coded value.

This proposal is a focused instance of the schema-driven validation problem described in #829.

Proposed behavior

Allow the requirement-description policy to be configured independently for change deltas and canonical specs.

For example:

validation:
  requirementDescriptions:
    delta:
      maxCharacters: 500
      severity: warning
    canonical:
      maxCharacters: 1200
      severity: warning

The exact configuration shape is open to maintainer direction. The important behavior is that the two lifecycle scopes can differ.

• delta applies to ADDED requirement descriptions authored in a change.
• canonical applies to requirements in accepted capability specs.
• maxCharacters accepts a positive integer, or null to disable the length finding for that scope.
• severity accepts info, warning, or error.
• Generated spec-writing instructions use the effective delta limit instead of always stating 500.
• Existing normal-versus-strict severity semantics remain unchanged.

For backward compatibility, omitted configuration could preserve today's behavior. Alternatively, the built-in schema could retain 500 for delta authoring while adopting a higher canonical default; that product decision can be made separately from enabling configuration.

Why scope-specific configuration is preferable

A single configurable number still assumes that authoring-time concision and long-lived canonical completeness are the same concern.

Separate policies preserve the useful 500-character authoring discipline while allowing a project to retain complete canonical contracts. They also make the current treatment of MODIFIED requirements coherent: a change can preserve a complete existing block without causing an unexpected canonical strict-validation failure after sync or archive.

Acceptance criteria

• Existing projects retain documented behavior when configuration is absent.
• ADDED delta requirements use the effective delta policy.
• Canonical requirements use the effective canonical policy.
• Normal and strict validation retain their established severity behavior.
• Project-local and store-backed validation resolve the same effective policy.
• Generated agent instructions state the effective delta limit and severity.
• Invalid values produce an actionable configuration error.
• JSON findings include a stable finding code, lifecycle scope, and effective limit.
• Tests cover omitted configuration, separate custom limits, disabled checks, invalid values, and exact boundary behavior.
• Documentation explains that the limit applies only to description text before the first scenario.

Alternatives considered

1. Keep one hard-coded limit: simple, but forces one writing-style heuristic across materially different lifecycle contexts.
2. Raise the global limit: reduces immediate failures but retains the same architectural problem.
3. Use non-strict validation: avoids the failure but weakens every other warning-based quality gate.
4. Project-local fork or patch: possible, but creates avoidable maintenance and upgrade drift.

Would maintainers prefer this as a narrow project-config option first, or as the first concrete validation rule migrated into the schema-driven mechanism proposed in #829?