Add Error Correction Log Interface & Standardize Recording Mechanism

[clay-good]

Note

Moved from issue #641, originally opened by @dragonTalon on 2026-02-01. Continuing the conversation here in Discussions — the original issue thread (including any comments) stays available at #641 for the record.

---

1. Background & Problem Statement​

When using OpenSpec for AI-assisted development, we frequently encounter subtle deviations​ in the AI-generated code (e.g., logical omissions, format inconsistencies, boundary condition errors). These issues require manual modifications after each applyoperation, and currently, there is no unified mechanism to record or manage these post-apply changes. This lack of traceability hinders debugging, prevents continuous improvement of AI outputs, and violates OpenSpec’s core principle of "specification as the single source of truth."

To address this, we propose adding an error correction log interface​ to systematically capture, store, and associate post-apply modifications with corresponding specification documents.

2. Proposed Solution​

2.1 Core Functional Requirements​

• We recommend introducing a dedicated fix.mdfile within the openspec/specs/directory to serve as the centralized repository for error corrections. This file will link each correction to the relevant specification (spec.md) and change proposal, enabling end-to-end traceability.

• Interface Operations: Support CRUD (Create, Read, Update, Delete) operations for correction entries via OpenSpec CLI or AI tools (e.g., CodeBuddy Code). Allow filtering by specPath, timestamp, or error type.

• Automated Association: Integrate with OpenSpec’s existing workflow (e.g., apply→ fix) to auto-generate fix.mdentries when manual modifications are detected. This reduces manual effort and ensures consistency.

2.2 Example Structure of fix.md​

## Error Correction Log (Fix Records)
### 1. JWT Expiration Check Omission
- **Associated Specification**: `openspec/specs/auth/spec.md` (## Authentication Requirements > ### Requirement: JWT Validation)  
- **Problem**: AI-generated code did not validate the `exp` (expiration time) field in JWT tokens.  
- **Modification**: Added `if (payload.exp < Date.now() / 1000) { throw new Error("Token expired"); }` to the `validateToken` function.  
- **Reason**: Compliance with RFC 7519 (JSON Web Token) standards for token expiration.  
- **Timestamp**: 2026-02-01T14:30:00Z.  

### 2. Password Strength Insufficient
- **Associated Specification**: `openspec/specs/user/spec.md` (## User Management Requirements > ### Requirement: Password Policy)  
- **Problem**: AI-generated password validation only checked for 6 characters (missing special character requirement).  
- **Modification**: Updated password validation logic to require 8+ characters with at least one special character.  
- **Reason**: Meets project security guidelines for password strength.  
- **Timestamp**: 2026-02-01T15:15:00Z.