eb1fc9f220
P2.6: Type Safety Cleanup - Replaced 'any' return types in vite-plugin.ts with concrete types (UserConfig, transform return type) - Documented TypeScript mixin 'any[]' exception in PlatformServiceMixin.ts - Audit confirmed: zero 'any' in codebase except documented TS mixin limitation - All external boundaries use 'unknown', all data payloads use 'Record<string, unknown>' P2.7: System Invariants Documentation - Created SYSTEM_INVARIANTS.md documenting all 6 enforced invariants - Added to docs/00-INDEX.md under Policy & Contracts section - Each invariant includes: What, Why, How, Where Progress Docs Updates: - Updated 00-STATUS.md: marked P2.6/P2.7 complete, added type safety invariant note - Updated 01-CHANGELOG-WORK.md: added 2025-12-22 entries for P2.6/P2.7 - Updated 03-TEST-RUNS.md: added P2.6 type safety audit test run - Updated P2-DESIGN.md: marked P2.6 acceptance criteria complete - Updated SYSTEM_INVARIANTS.md: added Type Safety Notes section Baseline Tag: - Created v1.0.11-p0-p1.4-p1.5-p2.6-p2.7-complete TypeScript compilation: ✅ PASSES Build: ✅ PASSES CI: ✅ All checks pass
94 lines
2.2 KiB
Markdown
94 lines
2.2 KiB
Markdown
# Open Questions
|
|
|
|
**Purpose:** Questions and uncertainties discovered during implementation, with proposed answers and decisions.
|
|
**Owner:** Development Team
|
|
**Last Updated:** 2025-12-22
|
|
**Status:** active
|
|
|
|
---
|
|
|
|
## Template
|
|
|
|
### Q: [Question Title]
|
|
|
|
**Context:**
|
|
[What led to this question? What problem are we trying to solve?]
|
|
|
|
**Files Involved:**
|
|
- `path/to/file1.ts`
|
|
- `path/to/file2.swift`
|
|
|
|
**Options:**
|
|
1. **Option A:** [Description]
|
|
- Pros: [list]
|
|
- Cons: [list]
|
|
|
|
2. **Option B:** [Description]
|
|
- Pros: [list]
|
|
- Cons: [list]
|
|
|
|
**Recommendation:**
|
|
[Which option is recommended and why]
|
|
|
|
**Decision:**
|
|
[Final decision if made, or "Pending"]
|
|
|
|
---
|
|
|
|
## Current Questions
|
|
|
|
*No open questions currently. All architectural decisions have been made.*
|
|
|
|
---
|
|
|
|
## Closed Questions
|
|
|
|
### Q: What is the authoritative CI entrypoint?
|
|
|
|
**Context:**
|
|
Need to establish a single source of truth for CI to avoid drift and ensure consistency.
|
|
|
|
**Decision:**
|
|
`./ci/run.sh` is canonical. It wraps `./scripts/verify.sh` and provides a stable interface for:
|
|
- CI runners
|
|
- Release gates
|
|
- Pre-merge checks
|
|
- Git hooks (`githooks/pre-push`)
|
|
- Makefile targets (`make ci`)
|
|
|
|
`./scripts/verify.sh` is an implementation detail/library function. External systems should call `./ci/run.sh`.
|
|
|
|
**Rationale:**
|
|
- Stable interface for automation
|
|
- Clear separation: entrypoint vs implementation
|
|
- Easy to add pre/post hooks in the future
|
|
- Consistent exit codes and output format
|
|
|
|
**Status:** ✅ **RESOLVED** (2025-12-22)
|
|
|
|
---
|
|
|
|
### Q: How to enforce core module purity?
|
|
|
|
**Context:**
|
|
Core module (`src/core/`) must remain platform-agnostic and portable. Need automated enforcement.
|
|
|
|
**Decision:**
|
|
Enforce via `verify.sh`:
|
|
- Platform import blocking: comprehensive regex detects Node builtins, Capacitor, React
|
|
- Export validation: Node-based check ensures `package.json.exports['./core']` exists
|
|
- Source checks run before build (works on clean checkouts)
|
|
- Artifact checks run after build (validates build outputs)
|
|
|
|
**Rationale:**
|
|
- Automated enforcement prevents regressions
|
|
- Clear error messages guide developers
|
|
- Policy encoded in tooling, not tribal knowledge
|
|
|
|
**Status:** ✅ **RESOLVED** (2025-12-22)
|
|
|
|
---
|
|
|
|
**Last Updated:** 2025-12-22
|
|
|