base-layer/promptkit
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 4 Wiki Activity

Plan the responsibility simplification sprint

Browse Source
This commit is contained in:
Eric Rakestraw
2026-11-05 19:24:09 +00:00
parent c69703b2b6
commit de46935a0e
2 changed files with 414 additions and 928 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1318
docs/roadmap/implementation.md
View File

File diff suppressed because it is too large Load Diff

24
docs/roadmap/responsibility-simplification.md
View File

@@ -14,9 +14,10 @@ All significant decisions are settled. Implementation is pending.
The current baseline is `f660b6e`. The production code remains at the audited
`1ff6d77` baseline; subsequent commits record the audit and accepted decisions.
The audit owns evidence and decision rationale; this document owns the selected
target and delivery scope. The older [audit remediation](audit-remediation.md)
and its completed implementation plan describe an earlier sprint, not this work.
A separate implementation plan will define prompt-sized stages for this scope.
target and delivery scope. The [implementation plan](implementation.md) owns the
ordered stages and validation for this work. The older
[audit remediation](audit-remediation.md) describes an earlier completed sprint;
its previous plan is retained in Git history, not the current implementation plan.
## Targeted End State
@@ -120,12 +121,11 @@ No composite validator or diagnostic framework is needed.
**Audit findings:** 5–6, with finding 8's preservation decision.
Plan these changes together. For affected paths, establish where values are
accepted, whether they can subsequently be mutated, and where they cross into
caller/client-owned mutable state. A small ownership inventory in the
implementation plan is sufficient. Include captured backend/profile lookup,
prepared details, execution results, injected-client and repair requests, and
smoke reports; do not optimize one path by moving its extra copy into another.
Acceptance and detachment have distinct responsibilities across captured
backend/profile lookup, prepared details, execution results, injected-client
and repair requests, and smoke reports. The target removes redundant traversals
across those paths together, rather than moving a copy into another helper.
The implementation plan records the corresponding ownership inventory.
Keep validation at actual input-acceptance boundaries. For previously accepted
values, use existing trusted detachment where a mutable copy is needed and
@@ -219,6 +219,6 @@ and duplicate state are actually gone rather than renamed or relocated.
The audit's test results describe the original baseline, not evidence of the
replacement implementation. Record actual implementation outcomes separately.
No additional product decision or evidence-gathering phase is required before
preparing the staged plan. Release selection/publication and retirement of the
older completed audit documents are separate work from this roadmap.
No significant product decisions remain open. Release selection/publication and
retirement of the older completed audit documents are separate work from this
roadmap.