mirror of
https://github.com/luxfi/safe-wallet.git
synced 2026-10-30 15:19:21 +00:00
TimandGitHub
41a84f681c
* refactor(hypernative): migrate to v3 feature architecture Migrate the Hypernative feature to the v3 feature architecture pattern with lazy loading, feature contracts, and proper public API boundaries. Key changes: - Create feature handle with contract.ts, feature.ts, and index.ts - Add lazy-loaded components: HypernativeLogo, HypernativeTooltip, HnAnalysisGroupCard, HnCustomChecksCard, HnInfoCard - Export hooks directly from index.ts (useHypernativeOAuth, useIsHypernativeEligible, useHypernativeAuth) - Move HypernativeCustomChecks from safe-shield to hypernative as HnCustomChecksCard - Move HypernativeInfo from safe-shield to hypernative as HnInfoCard - Create HnAnalysisGroupCard wrapper with Hypernative branding footer - Update all consumers to use useLoadFeature(HypernativeFeature) - Make AnalysisGroupCard generic with optional footer prop - Update test mocks to support useLoadFeature and useHasFeature Components accessing hypernative feature now use the proxy pattern: const hn = useLoadFeature(HypernativeFeature) <hn.HnInfoCard ... /> This enables code splitting and reduces initial bundle size by lazy-loading Hypernative code only when the feature flag is enabled. * docs: add hypernative v3 migration specification Add comprehensive specification documents for migrating the Hypernative feature to the v3 feature architecture pattern. * fix: storybook tests * refactor: rename useQueueAssessment to useHnQueueAssessment * refactor: remove unused exports from public API * refactor: consolidate imports to use public API * fix: gate all assessment requests behind feature flag Ensure Hypernative assessment requests are only sent when the HYPERNATIVE feature flag is enabled: - Queue batch assessments (QueueAssessmentProvider) - Queue transaction assessment visibility (useShowHypernativeAssessment) - Single transaction threat analysis (useThreatAnalysis, useNestedThreatAnalysis) When the feature is disabled, the system falls back to Blockaid analysis. * chore: trigger CI pipeline * chore: trigger CI pipeline * refactor: update import paths to use relative paths in Hypernative components and hooks
2.7 KiB
2.7 KiB
Specification Quality Checklist: Hypernative v3 Architecture Migration
Purpose: Validate specification completeness and quality before proceeding to planning
Created: 2026-01-28
Updated: 2026-01-28 (post-planning)
Feature: spec.md
Content Quality
- No implementation details (languages, frameworks, APIs)
- Focused on user value and business needs
- Written for non-technical stakeholders
- All mandatory sections completed
Requirement Completeness
- No [NEEDS CLARIFICATION] markers remain
- Requirements are testable and unambiguous
- Success criteria are measurable
- Success criteria are technology-agnostic (no implementation details)
- All acceptance scenarios are defined
- Edge cases are identified
- Scope is clearly bounded
- Dependencies and assumptions identified
Feature Readiness
- All functional requirements have clear acceptance criteria
- User scenarios cover primary flows
- Feature meets measurable outcomes defined in Success Criteria
- No implementation details leak into specification
Planning Checklist (Phase 1 Complete)
- Technical Context filled with all relevant details
- Constitution Check passed (all 6 principles)
- research.md created with 7 architectural decisions
- data-model.md created with public API definition
- contracts/hypernative-contract.ts created
- quickstart.md created with migration steps
- Agent context updated (CLAUDE.md)
Constitution Re-Check (Post-Design)
| Principle | Status | Verification |
|---|---|---|
| I. Type Safety | ✅ PASS | Contract uses typeof pattern, no any types |
| II. Branch Protection | ✅ PASS | On feature branch 001-migrate-hypernative-v3 |
| III. Cross-Platform | ✅ PASS | Web-only changes, no shared package impact |
| IV. Testing Discipline | ✅ PASS | Mock patterns documented, Jest + MSW approach |
| V. Feature Organization | ✅ PASS | Following src/features/ pattern with flags |
| VI. Theme System | ✅ PASS | No theme changes planned |
Notes
- This is a technical architecture migration, so user stories are developer-focused
- The specification correctly focuses on "what" behavior should be preserved, not "how" to implement
- All success criteria are verifiable through testing without knowing implementation details
- Manual migration approach chosen (codemod has build issues)
- ESLint rule at 'warn' level during migration, 'error' after completion
- Ready for Phase 2 task generation (
/speckit.tasks)