Plan the public facade refactor

This commit is contained in:
2026-09-22 04:21:13 +00:00
parent e4540aa619
commit 7a858c2365
3 changed files with 315 additions and 11 deletions

View File

@@ -3,9 +3,9 @@
## Status
Accepted direction; implementation has not begun. This feature roadmap defines
the intended end state and compatibility requirements. A separate staged
implementation plan will define the work sequence. Current GoDoc and durable
documentation remain authoritative until implementation lands.
the intended end state and compatibility requirements. The companion
[implementation plan](implementation.md) defines the work sequence. Current
GoDoc and durable documentation remain authoritative until implementation lands.
## Purpose
@@ -97,8 +97,8 @@ internal package or require duplicate forwarding APIs to achieve that shape.
## Compatibility Requirements
This is a behavior-preserving refactor. Inventory the actual exported surface,
including methods and fields, before relocation. An exported declaration is
This is a behavior-preserving refactor covering the actual exported surface,
including methods and fields. An exported declaration is
accessible even when it is absent from the consumer guide. Do not infer that
an apparently low-level declaration is safe to remove: injected model clients
and other intentional extension contracts may rely on it.
@@ -155,13 +155,12 @@ private internal state and the established sealed option mechanism. Protect
the no-internal-production-imports-of-root dependency rule without freezing an
incidental file layout or exact internal package inventory.
Compare the exported surface before and after the refactor. Use existing
behavioral coverage first, adding tests only for consequential gaps introduced
by the new boundary. Pay particular attention to option timing, conversion
ownership, typed errors, and prepared-execution lifecycle. Run the complete
Compatibility evidence includes an unchanged exported surface and behavioral
coverage of consequential boundary risks: option timing, conversion ownership,
typed errors, and prepared-execution lifecycle. Acceptance requires the complete
[maintainer validation workflow](../development.md#maintainer-validation),
including race checks and both offline examples, before accepting the result.
No live provider calls or sibling repository are required for validation.
including race checks and both offline examples. No live provider calls or
sibling repository are required for validation.
## Relationship To The Profile Policy Work