evandro/gemini-nexus
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

style(design): apply Minimal Dark Mode design system\n\n- Switched to complete Dark Mode (OLED-friendly)\n- Established standard color palette matching modern technical aesthetics\n- Changed font to Plus Jakarta Sans for increased legibility\n- Enforced dark mode as default in App.tsx\n- Fixed several React cascading render (setState in useEffect) warnings

Browse Source
This commit is contained in:
Gemini Nexus Bot committed 2026-04-28 03:49:34 -03:00
1 parent b80531f8a8
commit bac7b5591e
738 files changed
+138513 -138123
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

openspec/changes/update-device-fingerprint-hardening/design.md
+50 -50
View File
@@ -1,50 +1,50 @@
## Context
Device-fingerprint capability spans the data layer, switch-orchestration layer, and UI management layer.
Historical proposals split the same capability across multiple change IDs, which fragmented implementation and acceptance criteria.
This design combines "feature completeness + robustness" into a single constraint set to keep implementation, verification, and release aligned.
## Goals / Non-Goals
- Goals:
- Unify scope and acceptance criteria for device-fingerprint capability.
- Ensure behavioral consistency and diagnosability for local/cloud switching.
- Keep consistent behavior on default paths across Windows/macOS/Linux.
- Keep legacy-data compatibility predictable and verifiable.
- Non-Goals:
- Support for non-default runtime configuration paths.
- Business strategy expansion unrelated to this capability.
## Decisions
- Decision: Use a single change ID to manage the complete capability.
- Rationale: Reduce governance overhead caused by duplicate proposals.
- Decision: Apply fingerprint using a two-phase flow with strict pre-commit verification.
- Rationale: Reduce mixed-state risk caused by partial success.
- Decision: Use versioned payload + boundary validation for fingerprint/history data.
- Rationale: Avoid silent data contamination and define clear compatibility/failure boundaries.
- Decision: Use fail-fast semantics for switch failures and return structured failure reasons.
- Rationale: Make failure behavior predictable and observable.
- Decision: Trigger safe mode for temporary degradation after consecutive failures.
- Rationale: Keep switching flow available during fault windows.
## Risks / Trade-offs
- Risk: Stricter validation may reject legacy dirty data.
- Mitigation: Normalize missing optional fields; fail-fast only for critical structure errors.
- Risk: Validation and diagnostic extensions add minor performance cost.
- Mitigation: Keep validation lightweight and limited to critical boundaries.
- Risk: More UI management actions may increase user misoperations.
- Mitigation: Add confirmation interactions and unit-test coverage for failure branches.
## Migration Plan
1. Use `update-device-fingerprint-hardening` as the single active proposal.
2. Merge historical duplicate proposal content into this proposal (`proposal`/`design`/`tasks`/`spec`).
3. Close and remove duplicate proposal directories.
4. Deliver with unified task checklist and acceptance checklist.
## Open Questions
- Should safe mode exit only by time window, or also allow manual recovery?
- Should diagnostic snapshots be exposed in the renderer as a visual panel?
## Context
Device-fingerprint capability spans the data layer, switch-orchestration layer, and UI management layer.
Historical proposals split the same capability across multiple change IDs, which fragmented implementation and acceptance criteria.
This design combines "feature completeness + robustness" into a single constraint set to keep implementation, verification, and release aligned.
## Goals / Non-Goals
- Goals:
- Unify scope and acceptance criteria for device-fingerprint capability.
- Ensure behavioral consistency and diagnosability for local/cloud switching.
- Keep consistent behavior on default paths across Windows/macOS/Linux.
- Keep legacy-data compatibility predictable and verifiable.
- Non-Goals:
- Support for non-default runtime configuration paths.
- Business strategy expansion unrelated to this capability.
## Decisions
- Decision: Use a single change ID to manage the complete capability.
- Rationale: Reduce governance overhead caused by duplicate proposals.
- Decision: Apply fingerprint using a two-phase flow with strict pre-commit verification.
- Rationale: Reduce mixed-state risk caused by partial success.
- Decision: Use versioned payload + boundary validation for fingerprint/history data.
- Rationale: Avoid silent data contamination and define clear compatibility/failure boundaries.
- Decision: Use fail-fast semantics for switch failures and return structured failure reasons.
- Rationale: Make failure behavior predictable and observable.
- Decision: Trigger safe mode for temporary degradation after consecutive failures.
- Rationale: Keep switching flow available during fault windows.
## Risks / Trade-offs
- Risk: Stricter validation may reject legacy dirty data.
- Mitigation: Normalize missing optional fields; fail-fast only for critical structure errors.
- Risk: Validation and diagnostic extensions add minor performance cost.
- Mitigation: Keep validation lightweight and limited to critical boundaries.
- Risk: More UI management actions may increase user misoperations.
- Mitigation: Add confirmation interactions and unit-test coverage for failure branches.
## Migration Plan
1. Use `update-device-fingerprint-hardening` as the single active proposal.
2. Merge historical duplicate proposal content into this proposal (`proposal`/`design`/`tasks`/`spec`).
3. Close and remove duplicate proposal directories.
4. Deliver with unified task checklist and acceptance checklist.
## Open Questions
- Should safe mode exit only by time window, or also allow manual recovery?
- Should diagnostic snapshots be exposed in the renderer as a visual panel?