24 changed files with 2281 additions and 483 deletions
@ -1,316 +1,181 @@ |
|||
--- |
|||
description: |
|||
globs: |
|||
alwaysApply: true |
|||
--- |
|||
# Time Safari Context |
|||
|
|||
**Author**: Matthew Raymer |
|||
**Date**: 2025-08-19 |
|||
**Status**: 🎯 **ACTIVE** - Core application context |
|||
|
|||
## Project Overview |
|||
|
|||
Time Safari is an application designed to foster community building through gifts, |
|||
gratitude, and collaborative projects. The app should make it extremely easy and |
|||
intuitive for users of any age and capability to recognize contributions, build |
|||
trust networks, and organize collective action. It is built on services that |
|||
preserve privacy and data sovereignty. |
|||
Time Safari is an application designed to foster community building through |
|||
gifts, gratitude, and collaborative projects. The app makes it easy and |
|||
intuitive for users of any age and capability to recognize contributions, |
|||
build trust networks, and organize collective action. It is built on services |
|||
that preserve privacy and data sovereignty. |
|||
|
|||
The ultimate goals of Time Safari are two-fold: |
|||
## Core Goals |
|||
|
|||
1. **Connect** Make it easy, rewarding, and non-threatening for people to |
|||
connect with others who have similar interests, and to initiate activities |
|||
together. This helps people accomplish and learn from other individuals in |
|||
less-structured environments; moreover, it helps them discover who they want |
|||
to continue to support and with whom they want to maintain relationships. |
|||
1. **Connect**: Make it easy, rewarding, and non-threatening for people to |
|||
connect with others who have similar interests, and to initiate activities |
|||
together. |
|||
|
|||
2. **Reveal** Widely advertise the great support and rewards that are being |
|||
given and accepted freely, especially non-monetary ones. Using visuals and text, |
|||
display the kind of impact that gifts are making in the lives of others. Also |
|||
show useful and engaging reports of project statistics and personal accomplishments. |
|||
2. **Reveal**: Widely advertise the great support and rewards that are being |
|||
given and accepted freely, especially non-monetary ones, showing the impact |
|||
gifts make in people's lives. |
|||
|
|||
## Technical Foundation |
|||
|
|||
## Core Approaches |
|||
### Architecture |
|||
|
|||
Time Safari should help everyday users build meaningful connections and organize |
|||
collective efforts by: |
|||
- **Privacy-preserving claims architecture** via endorser.ch |
|||
- **Decentralized Identifiers (DIDs)**: User identities based on |
|||
public/private key pairs stored on devices |
|||
- **Cryptographic Verification**: All claims and confirmations are |
|||
cryptographically signed |
|||
- **User-Controlled Visibility**: Users explicitly control who can see their |
|||
identifiers and data |
|||
- **Cross-Platform**: Web (PWA), Mobile (Capacitor), Desktop (Electron) |
|||
|
|||
1. **Recognizing Contributions**: Creating permanent, verifiable records of gifts |
|||
and contributions people give to each other and their communities. |
|||
### Current Database State |
|||
|
|||
2. **Facilitating Collaboration**: Making it ridiculously easy for people to ask |
|||
for or propose help on projects and interests that matter to them. |
|||
- **Database**: SQLite via Absurd SQL (browser) and native SQLite |
|||
(mobile/desktop) |
|||
- **Legacy Support**: IndexedDB (Dexie) for backward compatibility |
|||
- **Status**: Modern database architecture fully implemented |
|||
|
|||
3. **Building Trust Networks**: Enabling users to maintain their network and activity |
|||
visibility. Developing reputation through verified contributions and references, |
|||
which can be selectively shown to others outside the network. |
|||
### Core Technologies |
|||
|
|||
4. **Preserving Privacy**: Ensuring personal identifiers are only shared with |
|||
explicitly authorized contacts, allowing private individuals including children |
|||
to participate safely. |
|||
- **Frontend**: Vue 3 + TypeScript + vue-facing-decorator |
|||
- **Styling**: TailwindCSS |
|||
- **Build**: Vite with platform-specific configs |
|||
- **Testing**: Playwright E2E, Jest unit tests |
|||
- **Database**: SQLite (Absurd SQL in browser), IndexedDB (legacy) |
|||
- **State**: Pinia stores |
|||
- **Platform Services**: Abstracted behind interfaces with factory pattern |
|||
|
|||
5. **Engaging Content**: Displaying people's records in compelling stories, and |
|||
highlighting those projects that are lifting people's lives long-term, both in |
|||
physical support and in emotional-spiritual-creative thriving. |
|||
## Development Principles |
|||
|
|||
### Code Organization |
|||
|
|||
## Technical Foundation |
|||
- **Platform Services**: Abstract platform-specific code behind interfaces |
|||
- **Service Factory**: Use `PlatformServiceFactory` for platform selection |
|||
- **Type Safety**: Strict TypeScript, no `any` types, use type guards |
|||
- **Modern Architecture**: Use current platform service patterns |
|||
|
|||
This application is built on a privacy-preserving claims architecture (via |
|||
endorser.ch) with these key characteristics: |
|||
### Architecture Patterns |
|||
|
|||
- **Decentralized Identifiers (DIDs)**: User identities are based on public/private |
|||
key pairs stored on their devices |
|||
- **Cryptographic Verification**: All claims and confirmations are |
|||
cryptographically signed |
|||
- **User-Controlled Visibility**: Users explicitly control who can see their |
|||
identifiers and data |
|||
- **Merkle-Chained Claims**: Claims are cryptographically chained for verification |
|||
and integrity |
|||
- **Native and Web App**: Works on Capacitor (iOS, Android), Desktop (Electron |
|||
and CEFPython), and web browsers |
|||
- **Dependency Injection**: Services injected via mixins and factory pattern |
|||
- **Interface Segregation**: Small, focused interfaces over large ones |
|||
- **Composition over Inheritance**: Prefer mixins and composition |
|||
- **Single Responsibility**: Each component/service has one clear purpose |
|||
|
|||
## User Journey |
|||
### Testing Strategy |
|||
|
|||
The typical progression of usage follows these stages: |
|||
- **E2E**: Playwright for critical user journeys |
|||
- **Unit**: Jest with F.I.R.S.T. principles |
|||
- **Platform Coverage**: Web + Capacitor (Pixel 5) in CI |
|||
- **Quality Assurance**: Comprehensive testing and validation |
|||
|
|||
1. **Gratitude & Recognition**: Users begin by expressing and recording gratitude |
|||
for gifts received, building a foundation of acknowledgment. |
|||
## Current Development Focus |
|||
|
|||
2. **Project Proposals**: Users propose projects and ideas, reaching out to connect |
|||
with others who share similar interests. |
|||
### Active Development |
|||
|
|||
3. **Action Triggers**: Offers of help serve as triggers and motivations to execute |
|||
proposed projects, moving from ideas to action. |
|||
- **Feature Development**: Build new functionality using modern platform |
|||
services |
|||
- **Performance Optimization**: Improve app performance and user experience |
|||
- **Platform Enhancement**: Leverage platform-specific capabilities |
|||
- **Code Quality**: Maintain high standards and best practices |
|||
|
|||
## Context for LLM Development |
|||
### Development Metrics |
|||
|
|||
When developing new functionality for Time Safari, consider these design principles: |
|||
- **Code Quality**: High standards maintained across all platforms |
|||
- **Performance**: Optimized for all target devices |
|||
- **Testing**: Comprehensive coverage maintained |
|||
- **User Experience**: Focus on intuitive, accessible interfaces |
|||
|
|||
1. **Accessibility First**: Features should be usable by non-technical users with |
|||
minimal learning curve. |
|||
## Platform-Specific Considerations |
|||
|
|||
2. **Privacy by Design**: All features must respect user privacy and data sovereignty. |
|||
### Web (PWA) |
|||
|
|||
3. **Progressive Enhancement**: Core functionality should work across all devices, |
|||
with richer experiences where supported. |
|||
- **QR Scanning**: WebInlineQRScanner |
|||
- **Deep Linking**: URL parameters |
|||
- **File System**: Limited browser APIs |
|||
- **Build**: `npm run build:web` (development build) |
|||
|
|||
4. **Voluntary Collaboration**: The system should enable but never coerce participation. |
|||
### Mobile (Capacitor) |
|||
|
|||
5. **Trust Building**: Features should help build verifiable trust between users. |
|||
- **QR Scanning**: @capacitor-mlkit/barcode-scanning |
|||
- **Deep Linking**: App URL open events |
|||
- **File System**: Capacitor Filesystem |
|||
- **Build**: `npm run build:capacitor` |
|||
|
|||
6. **Network Effects**: Consider how features scale as more users join the platform. |
|||
### Desktop (Electron) |
|||
|
|||
7. **Low Resource Requirements**: The system should be lightweight enough to run |
|||
on inexpensive devices users already own. |
|||
- **File System**: Node.js fs |
|||
- **Build**: `npm run build:electron` |
|||
- **Distribution**: AppImage, DEB, DMG packages |
|||
|
|||
## Use Cases to Support |
|||
## Development Workflow |
|||
|
|||
### Build Commands |
|||
|
|||
LLM development should focus on enhancing these key use cases: |
|||
```bash |
|||
# Web (development) |
|||
npm run build:web |
|||
|
|||
1. **Community Building**: Tools that help people find others with shared |
|||
interests and values. |
|||
# Mobile |
|||
npm run build:capacitor |
|||
npm run build:native |
|||
|
|||
2. **Project Coordination**: Features that make it easy to propose collaborative |
|||
projects and to submit suggestions and offers to existing ones. |
|||
# Desktop |
|||
npm run build:electron |
|||
npm run build:electron:appimage |
|||
npm run build:electron:deb |
|||
npm run build:electron:dmg |
|||
``` |
|||
|
|||
3. **Reputation Building**: Methods for users to showcase their contributions |
|||
and reliability, in contexts where they explicitly reveal that information. |
|||
### Testing Commands |
|||
|
|||
4. **Governance Experimentation**: Features that facilitate decision-making and |
|||
collective governance. |
|||
```bash |
|||
# Web E2E |
|||
npm run test:web |
|||
|
|||
## Constraints |
|||
|
|||
When developing new features, be mindful of these constraints: |
|||
# Mobile |
|||
npm run test:mobile |
|||
npm run test:android |
|||
npm run test:ios |
|||
|
|||
# Type checking |
|||
npm run type-check |
|||
npm run lint-fix |
|||
``` |
|||
|
|||
## Key Constraints |
|||
|
|||
1. **Privacy First**: User identifiers remain private except when explicitly |
|||
shared |
|||
2. **Platform Compatibility**: Features must work across all target platforms |
|||
3. **Performance**: Must remain performant on older/simpler devices |
|||
4. **Modern Architecture**: New features should use current platform services |
|||
5. **Offline Capability**: Key functionality should work offline when feasible |
|||
|
|||
## Use Cases to Support |
|||
|
|||
1. **Community Building**: Tools for finding others with shared interests |
|||
2. **Project Coordination**: Easy proposal and collaboration on projects |
|||
3. **Reputation Building**: Showcasing contributions and reliability |
|||
4. **Governance**: Facilitating decision-making and collective governance |
|||
|
|||
## Resources |
|||
|
|||
- **Testing**: `docs/migration-testing/` |
|||
- **Architecture**: `docs/architecture-decisions.md` |
|||
- **Build Context**: `docs/build-modernization-context.md` |
|||
|
|||
--- |
|||
|
|||
1. **Privacy Preservation**: User identifiers must remain private except when |
|||
explicitly shared. |
|||
## Status: Active application context |
|||
|
|||
2. **Platform Limitations**: Features must work within the constraints of the target |
|||
app platforms, while aiming to leverage the best platform technology available. |
|||
|
|||
3. **Endorser API Limitations**: Backend features are constrained by the endorser.ch |
|||
API capabilities. |
|||
|
|||
4. **Performance on Low-End Devices**: The application should remain performant |
|||
on older/simpler devices. |
|||
|
|||
5. **Offline-First When Possible**: Key functionality should work offline when feasible. |
|||
|
|||
## Project Technologies |
|||
|
|||
- Typescript using ES6 classes using vue-facing-decorator |
|||
- TailwindCSS |
|||
- Vite Build Tool |
|||
- Playwright E2E testing |
|||
- IndexDB |
|||
- Camera, Image uploads, QR Code reader, ... |
|||
|
|||
## Mobile Features |
|||
|
|||
- Deep Linking |
|||
- Local Notifications via a custom Capacitor plugin |
|||
|
|||
## Project Architecture |
|||
|
|||
- The application must work on web browser, PWA (Progressive Web Application), |
|||
desktop via Electron, and mobile via Capacitor |
|||
- Building for each platform is managed via Vite |
|||
|
|||
## Core Development Principles |
|||
|
|||
### DRY development |
|||
|
|||
- **Code Reuse** |
|||
- Extract common functionality into utility functions |
|||
- Create reusable components for UI patterns |
|||
- Implement service classes for shared business logic |
|||
- Use mixins for cross-cutting concerns |
|||
- Leverage TypeScript interfaces for shared type definitions |
|||
|
|||
- **Component Patterns** |
|||
- Create base components for common UI elements |
|||
- Implement higher-order components for shared behavior |
|||
- Use slot patterns for flexible component composition |
|||
- Create composable services for business logic |
|||
- Implement factory patterns for component creation |
|||
|
|||
- **State Management** |
|||
- Centralize state in Pinia stores |
|||
- Use computed properties for derived state |
|||
- Implement shared state selectors |
|||
- Create reusable state mutations |
|||
- Use action creators for common operations |
|||
|
|||
- **Error Handling** |
|||
- Implement centralized error handling |
|||
- Create reusable error components |
|||
- Use error boundary components |
|||
- Implement consistent error logging |
|||
- Create error type definitions |
|||
|
|||
- **Type Definitions** |
|||
- Create shared interfaces for common data structures |
|||
- Use type aliases for complex types |
|||
- Implement generic types for reusable components |
|||
- Create utility types for common patterns |
|||
- Use discriminated unions for state management |
|||
|
|||
- **API Integration** |
|||
- Create reusable API client classes |
|||
- Implement request/response interceptors |
|||
- Use consistent error handling patterns |
|||
- Create type-safe API endpoints |
|||
- Implement caching strategies |
|||
|
|||
- **Platform Services** |
|||
- Abstract platform-specific code behind interfaces |
|||
- Create platform-agnostic service layers |
|||
- Implement feature detection |
|||
- Use dependency injection for services |
|||
- Create service factories |
|||
|
|||
- **Testing** |
|||
- Create reusable test utilities |
|||
- Implement test factories |
|||
- Use shared test configurations |
|||
- Create reusable test helpers |
|||
- Implement consistent test patterns |
|||
- F.I.R.S.T. (for Unit Tests) |
|||
F – Fast |
|||
I – Independent |
|||
R – Repeatable |
|||
S – Self-validating |
|||
T – Timely |
|||
|
|||
### SOLID Principles |
|||
|
|||
- **Single Responsibility**: Each class/component should have only one reason to |
|||
change |
|||
- Components should focus on one specific feature (e.g., QR scanning, DID management) |
|||
- Services should handle one type of functionality (e.g., platform services, |
|||
crypto services) |
|||
- Utilities should provide focused helper functions |
|||
|
|||
- **Open/Closed**: Software entities should be open for extension but closed for |
|||
modification |
|||
- Use interfaces for service definitions |
|||
- Implement plugin architecture for platform-specific features |
|||
- Allow component behavior extension through props and events |
|||
|
|||
- **Liskov Substitution**: Objects should be replaceable with their subtypes |
|||
- Platform services should work consistently across web/mobile |
|||
- Authentication providers should be interchangeable |
|||
- Storage implementations should be swappable |
|||
|
|||
- **Interface Segregation**: Clients shouldn't depend on interfaces they don't use |
|||
- Break down large service interfaces into smaller, focused ones |
|||
- Component props should be minimal and purposeful |
|||
- Event emissions should be specific and targeted |
|||
|
|||
- **Dependency Inversion**: High-level modules shouldn't depend on low-level modules |
|||
- Use dependency injection for services |
|||
- Abstract platform-specific code behind interfaces |
|||
- Implement factory patterns for component creation |
|||
|
|||
### Law of Demeter |
|||
|
|||
- Components should only communicate with immediate dependencies |
|||
- Avoid chaining method calls (e.g., `this.service.getUser().getProfile().getName()`) |
|||
- Use mediator patterns for complex component interactions |
|||
- Implement facade patterns for subsystem access |
|||
- Keep component communication through defined events and props |
|||
|
|||
### Composition over Inheritance |
|||
|
|||
- Prefer building components through composition |
|||
- Use mixins for shared functionality |
|||
- Implement feature toggles through props |
|||
- Create higher-order components for common patterns |
|||
- Use service composition for complex features |
|||
|
|||
### Interface Segregation |
|||
|
|||
- Define clear interfaces for services |
|||
- Keep component APIs minimal and focused |
|||
- Split large interfaces into smaller, specific ones |
|||
- Use TypeScript interfaces for type definitions |
|||
- Implement role-based interfaces for different use cases |
|||
|
|||
### Fail Fast |
|||
|
|||
- Validate inputs early in the process |
|||
- Use TypeScript strict mode |
|||
- Implement comprehensive error handling |
|||
- Add runtime checks for critical operations |
|||
- Use assertions for development-time validation |
|||
|
|||
### Principle of Least Astonishment |
|||
|
|||
- Follow Vue.js conventions consistently |
|||
- Use familiar naming patterns |
|||
- Implement predictable component behaviors |
|||
- Maintain consistent error handling |
|||
- Keep UI interactions intuitive |
|||
|
|||
### Information Hiding |
|||
|
|||
- Encapsulate implementation details |
|||
- Use private class members |
|||
- Implement proper access modifiers |
|||
- Hide complex logic behind simple interfaces |
|||
- Use TypeScript's access modifiers effectively |
|||
|
|||
### Single Source of Truth |
|||
|
|||
- Use Pinia for state management |
|||
- Maintain one source for user data |
|||
- Centralize configuration management |
|||
- Use computed properties for derived state |
|||
- Implement proper state synchronization |
|||
|
|||
### Principle of Least Privilege |
|||
|
|||
- Implement proper access control |
|||
- Use minimal required permissions |
|||
- Follow privacy-by-design principles |
|||
- Restrict component access to necessary data |
|||
- Implement proper authentication/authorization |
|||
- **Priority**: Critical |
|||
- **Estimated Effort**: Ongoing reference |
|||
- **Dependencies**: Vue 3, TypeScript, SQLite, Capacitor, Electron |
|||
- **Stakeholders**: Development team, Product team |
|||
|
|||
@ -1,32 +1,61 @@ |
|||
--- |
|||
alwaysApply: true |
|||
description: when doing anything with capacitor assets |
|||
alwaysApply: false |
|||
--- |
|||
# Asset Configuration Directive |
|||
*Scope: Assets Only (icons, splashes, image pipelines) — not overall build orchestration* |
|||
|
|||
**Author**: Matthew Raymer |
|||
**Date**: 2025-08-19 |
|||
**Status**: 🎯 **ACTIVE** - Asset management guidelines |
|||
|
|||
*Scope: Assets Only (icons, splashes, image pipelines) — not overall build |
|||
orchestration* |
|||
|
|||
## Intent |
|||
|
|||
- Version **asset configuration files** (optionally dev-time generated). |
|||
- **Do not** version platform asset outputs (Android/iOS/Electron); generate them **at build-time** with standard tools. |
|||
- **Do not** version platform asset outputs (Android/iOS/Electron); generate |
|||
them **at build-time** with standard tools. |
|||
- Keep existing per-platform build scripts unchanged. |
|||
|
|||
## Source of Truth |
|||
|
|||
- **Preferred (Capacitor default):** `resources/` as the single master source. |
|||
- **Alternative:** `assets/` is acceptable **only** if `capacitor-assets` is explicitly configured to read from it. |
|||
- **Never** maintain both `resources/` and `assets/` as parallel sources. Migrate and delete the redundant folder. |
|||
- **Alternative:** `assets/` is acceptable **only** if `capacitor-assets` is |
|||
explicitly configured to read from it. |
|||
- **Never** maintain both `resources/` and `assets/` as parallel sources. |
|||
Migrate and delete the redundant folder. |
|||
|
|||
## Config Files |
|||
|
|||
- Live under: `config/assets/` (committed). |
|||
- Examples: |
|||
- `config/assets/capacitor-assets.config.json` (or the path the tool expects) |
|||
- `config/assets/capacitor-assets.config.json` (or the path the tool |
|||
expects) |
|||
- `config/assets/android.assets.json` |
|||
- `config/assets/ios.assets.json` |
|||
- `config/assets/common.assets.yaml` (optional shared layer) |
|||
- **Dev-time generation allowed** for these configs; **build-time generation is forbidden**. |
|||
- **Dev-time generation allowed** for these configs; **build-time |
|||
generation is forbidden**. |
|||
|
|||
## Build-Time Behavior |
|||
|
|||
- Build generates platform assets (not configs) using the standard chain: |
|||
```bash |
|||
npm run build:capacitor # web build via Vite (.mts) |
|||
npx cap sync |
|||
|
|||
```bash |
|||
npm run build:capacitor # web build via Vite (.mts) |
|||
npx cap sync |
|||
npx capacitor-assets generate # produces platform assets; not committed |
|||
# then platform-specific build steps |
|||
``` |
|||
|
|||
--- |
|||
|
|||
**Status**: Active asset management directive |
|||
**Priority**: Medium |
|||
**Estimated Effort**: Ongoing reference |
|||
**Dependencies**: capacitor-assets toolchain |
|||
**Stakeholders**: Development team, Build team |
|||
|
|||
npx capacitor-assets generate # produces platform assets; not committed |
|||
# then platform-specific build steps |
|||
|
|||
@ -1,76 +1,117 @@ |
|||
# Investigation Report Example |
|||
|
|||
**Author**: Matthew Raymer |
|||
**Date**: 2025-08-19 |
|||
**Status**: 🎯 **ACTIVE** - Investigation methodology example |
|||
|
|||
## Investigation — Registration Dialog Test Flakiness |
|||
|
|||
## Objective |
|||
Identify root cause of flaky tests related to registration dialogs in contact import scenarios. |
|||
|
|||
Identify root cause of flaky tests related to registration dialogs in contact |
|||
import scenarios. |
|||
|
|||
## System Map |
|||
- User action → ContactInputForm → ContactsView.addContact() → handleRegistrationPrompt() |
|||
|
|||
- User action → ContactInputForm → ContactsView.addContact() → |
|||
handleRegistrationPrompt() |
|||
- setTimeout(1000ms) → Modal dialog → User response → Registration API call |
|||
- Test execution → Wait for dialog → Assert dialog content → Click response button |
|||
- Test execution → Wait for dialog → Assert dialog content → Click response |
|||
button |
|||
|
|||
## Findings (Evidence) |
|||
- **1-second timeout causes flakiness** — evidence: `src/views/ContactsView.vue:971-1000`; setTimeout(..., 1000) in handleRegistrationPrompt() |
|||
- **Import flow bypasses dialogs** — evidence: `src/views/ContactImportView.vue:500-520`; importContacts() calls $insertContact() directly, no handleRegistrationPrompt() |
|||
- **Dialog only appears in direct add flow** — evidence: `src/views/ContactsView.vue:774-800`; addContact() calls handleRegistrationPrompt() after database insert |
|||
|
|||
- **1-second timeout causes flakiness** — evidence: |
|||
`src/views/ContactsView.vue:971-1000`; setTimeout(..., 1000) in |
|||
handleRegistrationPrompt() |
|||
- **Import flow bypasses dialogs** — evidence: |
|||
`src/views/ContactImportView.vue:500-520`; importContacts() calls |
|||
$insertContact() directly, no handleRegistrationPrompt() |
|||
- **Dialog only appears in direct add flow** — evidence: |
|||
`src/views/ContactsView.vue:774-800`; addContact() calls |
|||
handleRegistrationPrompt() after database insert |
|||
|
|||
## Hypotheses & Failure Modes |
|||
- H1: 1-second timeout makes dialog appearance unpredictable; would fail when tests run faster than 1000ms |
|||
- H2: Test environment timing differs from development; watch for CI vs local test differences |
|||
|
|||
- H1: 1-second timeout makes dialog appearance unpredictable; would fail when |
|||
tests run faster than 1000ms |
|||
- H2: Test environment timing differs from development; watch for CI vs local |
|||
test differences |
|||
|
|||
## Corrections |
|||
- Updated: "Multiple dialogs interfere with imports" → "Import flow never triggers dialogs - they only appear in direct contact addition" |
|||
- Updated: "Complex batch registration needed" → "Simple timeout removal and test mode flag sufficient" |
|||
|
|||
- Updated: "Multiple dialogs interfere with imports" → "Import flow never |
|||
triggers dialogs - they only appear in direct contact addition" |
|||
- Updated: "Complex batch registration needed" → "Simple timeout removal and |
|||
test mode flag sufficient" |
|||
|
|||
## Diagnostics (Next Checks) |
|||
|
|||
- [ ] Repro on CI environment vs local |
|||
- [ ] Measure actual dialog appearance timing |
|||
- [ ] Test with setTimeout removed |
|||
- [ ] Verify import flow doesn't call handleRegistrationPrompt |
|||
|
|||
## Risks & Scope |
|||
- Impacted: Contact addition tests, registration workflow tests; Data: None; Users: Test suite reliability |
|||
|
|||
- Impacted: Contact addition tests, registration workflow tests; Data: None; |
|||
Users: Test suite reliability |
|||
|
|||
## Decision / Next Steps |
|||
|
|||
- Owner: Development Team; By: 2025-01-28 |
|||
- Action: Remove 1-second timeout + add test mode flag; Exit criteria: Tests pass consistently |
|||
- Action: Remove 1-second timeout + add test mode flag; Exit criteria: Tests |
|||
pass consistently |
|||
|
|||
## References |
|||
|
|||
- `src/views/ContactsView.vue:971-1000` |
|||
- `src/views/ContactImportView.vue:500-520` |
|||
- `src/views/ContactsView.vue:774-800` |
|||
|
|||
## Competence Hooks |
|||
- Why this works: Code path tracing revealed separate execution flows, evidence disproved initial assumptions |
|||
- Common pitfalls: Assuming related functionality without tracing execution paths, over-engineering solutions to imaginary problems |
|||
- Next skill: Learn to trace code execution before proposing architectural changes |
|||
- Teach-back: "What evidence shows that contact imports bypass registration dialogs?" |
|||
|
|||
--- |
|||
- Why this works: Code path tracing revealed separate execution flows, |
|||
evidence disproved initial assumptions |
|||
- Common pitfalls: Assuming related functionality without tracing execution |
|||
paths, over-engineering solutions to imaginary problems |
|||
- Next skill: Learn to trace code execution before proposing architectural |
|||
changes |
|||
- Teach-back: "What evidence shows that contact imports bypass registration |
|||
dialogs?" |
|||
|
|||
## Key Learning Points |
|||
|
|||
### Evidence-First Approach |
|||
|
|||
This investigation demonstrates the importance of: |
|||
|
|||
1. **Tracing actual code execution** rather than making assumptions |
|||
2. **Citing specific evidence** with file:line references |
|||
3. **Validating problem scope** before proposing solutions |
|||
4. **Considering simpler alternatives** before complex architectural changes |
|||
|
|||
### Code Path Tracing Value |
|||
|
|||
By tracing the execution paths, we discovered: |
|||
|
|||
- Import flow and direct add flow are completely separate |
|||
- The "multiple dialog interference" problem didn't exist |
|||
- A simple timeout removal would solve the actual issue |
|||
|
|||
### Prevention of Over-Engineering |
|||
|
|||
The investigation prevented: |
|||
|
|||
- Unnecessary database schema changes |
|||
- Complex batch registration systems |
|||
- Migration scripts for non-existent problems |
|||
- Architectural changes based on assumptions |
|||
description: |
|||
globs: |
|||
alwaysApply: false |
|||
|
|||
--- |
|||
|
|||
**Status**: Active investigation methodology |
|||
**Priority**: High |
|||
**Estimated Effort**: Ongoing reference |
|||
**Dependencies**: software_development.mdc |
|||
**Stakeholders**: Development team, QA team |
|||
|
|||
@ -0,0 +1,329 @@ |
|||
--- |
|||
alwaysApply: true |
|||
--- |
|||
# Time Handling in Development Workflow |
|||
|
|||
**Author**: Matthew Raymer |
|||
**Date**: 2025-08-17 |
|||
**Status**: 🎯 **ACTIVE** - Production Ready |
|||
|
|||
## Overview |
|||
|
|||
This guide establishes **how time should be referenced and used** across the |
|||
development workflow. It is not tied to any one project, but applies to **all |
|||
feature development, issue investigations, ADRs, and documentation**. |
|||
|
|||
## General Principles |
|||
|
|||
- **Explicit over relative**: Always prefer absolute dates (`2025-08-17`) over |
|||
relative references like "last week." |
|||
- **ISO 8601 Standard**: Use `YYYY-MM-DD` format for all date references in |
|||
docs, issues, ADRs, and commits. |
|||
- **Time zones**: Default to **UTC** unless explicitly tied to user-facing |
|||
behavior. |
|||
- **Precision**: Only specify as much precision as needed (date vs. datetime vs. |
|||
timestamp). |
|||
- **Consistency**: Align time references across ADRs, commits, and investigation |
|||
reports. |
|||
|
|||
## In Documentation & ADRs |
|||
|
|||
- Record decision dates using **absolute ISO dates**. |
|||
- For ongoing timelines, state start and end explicitly (e.g., `2025-08-01` → |
|||
`2025-08-17`). |
|||
- Avoid ambiguous terms like *recently*, *last month*, or *soon*. |
|||
- For time-based experiments (e.g., A/B tests), always include: |
|||
|
|||
- Start date |
|||
- Expected duration |
|||
- Review date checkpoint |
|||
|
|||
## In Code & Commits |
|||
|
|||
- Use **UTC timestamps** in logs, DB migrations, and serialized formats. |
|||
- In commits, link changes to **date-bound ADRs or investigation docs**. |
|||
- For migrations, include both **applied date** and **intended version window**. |
|||
- Use constants for known fixed dates; avoid hardcoding arbitrary strings. |
|||
|
|||
## In Investigations & Research |
|||
|
|||
- Capture **when** an issue occurred (absolute time or version tag). |
|||
- When describing failures: note whether they are **time-sensitive** (e.g., after |
|||
migrations, cache expirations). |
|||
- Record diagnostic timelines in ISO format (not relative). |
|||
- For performance regressions, annotate both **baseline timeframe** and |
|||
**measurement timeframe**. |
|||
|
|||
## Collaboration Hooks |
|||
|
|||
- During reviews, verify **time references are clear, absolute, and |
|||
standardized**. |
|||
- In syncs, reframe relative terms ("this week") into shared absolute |
|||
references. |
|||
- Tag ADRs with both **date created** and **review by** checkpoints. |
|||
|
|||
## Self-Check Before Submitting |
|||
|
|||
- [ ] Did I check the time using the **developer's actual system time and |
|||
timezone**? |
|||
- [ ] Am I using absolute ISO dates? |
|||
- [ ] Is UTC assumed unless specified otherwise? |
|||
- [ ] Did I avoid ambiguous relative terms? |
|||
- [ ] If duration matters, did I specify both start and end? |
|||
- [ ] For future work, did I include a review/revisit date? |
|||
|
|||
## Real-Time Context in Developer Interactions |
|||
|
|||
- The model must always resolve **"current time"** using the **developer's |
|||
actual system time and timezone**. |
|||
- When generating timestamps (e.g., in investigation logs, ADRs, or examples), |
|||
the model should: |
|||
|
|||
- Use the **developer's current local time** by default. |
|||
- Indicate the timezone explicitly (e.g., `2025-08-17T10:32-05:00`). |
|||
- Optionally provide UTC alongside if context requires cross-team clarity. |
|||
|
|||
- When interpreting relative terms like *now*, *today*, *last week*: |
|||
|
|||
- Resolve them against the **developer's current time**. |
|||
- Convert them into **absolute ISO-8601 values** in the output. |
|||
|
|||
## LLM Time Checking Instructions |
|||
|
|||
**CRITICAL**: The LLM must actively query the system for current time rather |
|||
than assuming or inventing times. |
|||
|
|||
### How to Check Current Time |
|||
|
|||
#### 1. **Query System Time (Required)** |
|||
|
|||
- **Always start** by querying the current system time using available tools |
|||
- **Never assume** what the current time is |
|||
- **Never use** placeholder values like "current time" or "now" |
|||
|
|||
#### 2. **Available Time Query Methods** |
|||
|
|||
- **System Clock**: Use `date` command or equivalent system time function |
|||
- **Programming Language**: Use language-specific time functions (e.g., |
|||
`Date.now()`, `datetime.now()`) |
|||
- **Environment Variables**: Check for time-related environment variables |
|||
- **API Calls**: Use time service APIs if available |
|||
|
|||
#### 3. **Required Time Information** |
|||
|
|||
When querying time, always obtain: |
|||
|
|||
- **Current Date**: YYYY-MM-DD format |
|||
- **Current Time**: HH:MM:SS format (24-hour) |
|||
- **Timezone**: Current system timezone or UTC offset |
|||
- **UTC Equivalent**: Convert local time to UTC for cross-team clarity |
|||
|
|||
#### 4. **Time Query Examples** |
|||
|
|||
```bash |
|||
# Example: Query system time |
|||
$ date |
|||
# Expected output: Mon Aug 17 10:32:45 EDT 2025 |
|||
|
|||
# Example: Query UTC time |
|||
$ date -u |
|||
# Expected output: Mon Aug 17 14:32:45 UTC 2025 |
|||
``` |
|||
|
|||
```python |
|||
# Example: Python time query |
|||
import datetime |
|||
current_time = datetime.datetime.now() |
|||
utc_time = datetime.datetime.utcnow() |
|||
print(f"Local: {current_time}") |
|||
print(f"UTC: {utc_time}") |
|||
``` |
|||
|
|||
```javascript |
|||
// Example: JavaScript time query |
|||
const now = new Date(); |
|||
const utc = new Date().toISOString(); |
|||
console.log(`Local: ${now}`); |
|||
console.log(`UTC: ${utc}`); |
|||
``` |
|||
|
|||
#### 5. **LLM Time Checking Workflow** |
|||
|
|||
1. **Query**: Actively query system for current time |
|||
2. **Validate**: Confirm time data is reasonable and current |
|||
3. **Format**: Convert to ISO 8601 format |
|||
4. **Context**: Provide both local and UTC times when helpful |
|||
5. **Document**: Show the source of time information |
|||
|
|||
#### 6. **Error Handling for Time Queries** |
|||
|
|||
- **If time query fails**: Ask user for current time or use "unknown time" |
|||
with explanation |
|||
- **If timezone unclear**: Default to UTC and ask for clarification |
|||
- **If time seems wrong**: Verify with user before proceeding |
|||
- **Always log**: Record when and how time was obtained |
|||
|
|||
#### 7. **Time Query Verification** |
|||
|
|||
Before using queried time, verify: |
|||
|
|||
- [ ] Time is recent (within last few minutes) |
|||
- [ ] Timezone information is available |
|||
- [ ] UTC conversion is accurate |
|||
- [ ] Format follows ISO 8601 standard |
|||
|
|||
## Model Behavior Rules |
|||
|
|||
- **Never invent a "fake now"**: All "current time" references must come from |
|||
the real system clock available at runtime. |
|||
- **Check developer time zone**: If ambiguous, ask for clarification (e.g., |
|||
"Should I use UTC or your local timezone?"). |
|||
- **Format for clarity**: |
|||
|
|||
- Local time: `YYYY-MM-DDTHH:mm±hh:mm` |
|||
- UTC equivalent (if needed): `YYYY-MM-DDTHH:mmZ` |
|||
|
|||
## Examples |
|||
|
|||
### Good |
|||
|
|||
- "Feature flag rollout started on `2025-08-01` and will be reviewed on |
|||
`2025-08-21`." |
|||
- "Migration applied on `2025-07-15T14:00Z`." |
|||
- "Issue reproduced on `2025-08-17T09:00-05:00 (local)` / |
|||
`2025-08-17T14:00Z (UTC)`." |
|||
|
|||
### Bad |
|||
|
|||
- "Feature flag rolled out last week." |
|||
- "Migration applied recently." |
|||
- "Now is August, so we assume this was last month." |
|||
|
|||
### More Examples |
|||
|
|||
#### Issue Reports |
|||
|
|||
- ✅ **Good**: "User reported login failure at `2025-08-17T14:30:00Z`. Issue |
|||
persisted until `2025-08-17T15:45:00Z`." |
|||
- ❌ **Bad**: "User reported login failure earlier today. Issue lasted for a |
|||
while." |
|||
|
|||
#### Release Planning |
|||
|
|||
- ✅ **Good**: "Feature X scheduled for release on `2025-08-25`. Testing |
|||
window: `2025-08-20` to `2025-08-24`." |
|||
- ❌ **Bad**: "Feature X will be released next week after testing." |
|||
|
|||
#### Performance Monitoring |
|||
|
|||
- ✅ **Good**: "Baseline performance measured on `2025-08-10T09:00:00Z`. |
|||
Regression detected on `2025-08-15T14:00:00Z`." |
|||
- ❌ **Bad**: "Performance was good last week but got worse this week." |
|||
|
|||
## Technical Implementation Notes |
|||
|
|||
### UTC Storage Principle |
|||
|
|||
- **Store all timestamps in UTC** in databases, logs, and serialized formats |
|||
- **Convert to local time only for user display** |
|||
- **Use ISO 8601 format** for all storage: `YYYY-MM-DDTHH:mm:ss.sssZ` |
|||
|
|||
### Common Implementation Patterns |
|||
|
|||
#### Database Storage |
|||
|
|||
```sql |
|||
-- ✅ Good: Store in UTC |
|||
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, |
|||
updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP |
|||
|
|||
-- ❌ Bad: Store in local time |
|||
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, |
|||
updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP |
|||
``` |
|||
|
|||
#### API Responses |
|||
|
|||
```json |
|||
// ✅ Good: Include both UTC and local time |
|||
{ |
|||
"eventTime": "2025-08-17T14:00:00Z", |
|||
"localTime": "2025-08-17T10:00:00-04:00", |
|||
"timezone": "America/New_York" |
|||
} |
|||
|
|||
// ❌ Bad: Only local time |
|||
{ |
|||
"eventTime": "2025-08-17T10:00:00-04:00" |
|||
} |
|||
``` |
|||
|
|||
#### Logging |
|||
|
|||
```python |
|||
# ✅ Good: Log in UTC with timezone info |
|||
logger.info(f"User action at {datetime.utcnow().isoformat()}Z (UTC)") |
|||
|
|||
# ❌ Bad: Log in local time |
|||
logger.info(f"User action at {datetime.now()}") |
|||
``` |
|||
|
|||
### Timezone Handling Best Practices |
|||
|
|||
#### 1. Always Store Timezone Information |
|||
|
|||
- Include IANA timezone identifier (e.g., `America/New_York`) |
|||
- Store UTC offset at time of creation |
|||
- Handle daylight saving time transitions automatically |
|||
|
|||
#### 2. User Display Considerations |
|||
|
|||
- Convert UTC to user's preferred timezone |
|||
- Show timezone abbreviation when helpful |
|||
- Use relative time for recent events ("2 hours ago") |
|||
|
|||
#### 3. Edge Case Handling |
|||
|
|||
- **Daylight Saving Time**: Use timezone-aware libraries |
|||
- **Leap Seconds**: Handle gracefully (rare but important) |
|||
- **Invalid Times**: Validate before processing |
|||
|
|||
### Common Mistakes to Avoid |
|||
|
|||
#### 1. Timezone Confusion |
|||
|
|||
- ❌ **Don't**: Assume server timezone is user timezone |
|||
- ✅ **Do**: Always convert UTC to user's local time for display |
|||
|
|||
#### 2. Format Inconsistency |
|||
|
|||
- ❌ **Don't**: Mix different time formats in the same system |
|||
- ✅ **Do**: Standardize on ISO 8601 for all storage |
|||
|
|||
#### 3. Relative Time References |
|||
|
|||
- ❌ **Don't**: Use relative terms in persistent storage |
|||
- ✅ **Do**: Convert relative terms to absolute timestamps immediately |
|||
|
|||
## References |
|||
|
|||
- [ISO 8601 Date and Time Standard](https://en.wikipedia.org/wiki/ISO_8601) |
|||
- [IANA Timezone Database](https://www.iana.org/time-zones) |
|||
- [ADR Template](./adr_template.md) |
|||
- [Research & Diagnostic Workflow](./research_diagnostic.mdc) |
|||
|
|||
--- |
|||
|
|||
**Rule of Thumb**: Every time reference in development artifacts should be |
|||
**clear in 6 months without context**, and aligned to the **developer's actual |
|||
current time**. |
|||
|
|||
**Technical Rule of Thumb**: **Store in UTC, display in local time, always |
|||
include timezone context.** |
|||
|
|||
--- |
|||
|
|||
**Status**: Active |
|||
**Version**: 1.0 |
|||
**Maintainer**: Matthew Raymer |
|||
**Next Review**: 2025-09-17 |
|||
@ -0,0 +1,182 @@ |
|||
# TimeSafari Debug Hook Guide |
|||
|
|||
**Complete Guide for Team Members** |
|||
|
|||
**Date**: 2025-01-27 |
|||
**Author**: Matthew Raymer |
|||
**Status**: ✅ **ACTIVE** - Ready for production use |
|||
|
|||
## 🎯 Overview |
|||
|
|||
A pre-commit hook that automatically detects and prevents debug code from reaching protected branches (master, main, production, release, stable). This ensures production code remains clean while allowing free development on feature branches. |
|||
|
|||
## 🚀 Quick Installation |
|||
|
|||
**From within the TimeSafari repository:** |
|||
|
|||
```bash |
|||
./scripts/install-debug-hook.sh |
|||
``` |
|||
|
|||
This automatically installs, updates, and verifies the hook in your current |
|||
repository. **Note**: Hooks are not automatically installed - you must run this |
|||
script deliberately to enable debug code checking. |
|||
|
|||
## 🔧 Manual Installation |
|||
|
|||
**Copy files manually:** |
|||
|
|||
```bash |
|||
cp scripts/git-hooks/pre-commit /path/to/your/repo/.git/hooks/ |
|||
cp scripts/git-hooks/debug-checker.config /path/to/your/repo/.git/hooks/ |
|||
chmod +x /path/to/your/repo/.git/hooks/pre-commit |
|||
``` |
|||
|
|||
## 📋 What Gets Installed |
|||
|
|||
- **`pre-commit`** - Main hook script (executable) |
|||
- **`debug-checker.config`** - Configuration file |
|||
- **`README.md`** - Documentation and troubleshooting |
|||
|
|||
**Note**: Hooks are stored in `scripts/git-hooks/` and must be deliberately |
|||
installed by each developer. They are not automatically active. |
|||
|
|||
## 🎯 How It Works |
|||
|
|||
1. **Deliberate Installation**: Hooks must be explicitly installed by each |
|||
developer |
|||
2. **Branch Detection**: Only runs on protected branches |
|||
3. **File Filtering**: Automatically skips tests, scripts, and documentation |
|||
4. **Pattern Matching**: Detects debug code using regex patterns |
|||
5. **Commit Prevention**: Blocks commits containing debug code |
|||
|
|||
## 🔒 Installation Philosophy |
|||
|
|||
**Why deliberate installation?** |
|||
|
|||
- **Developer choice**: Each developer decides whether to use the hook |
|||
- **No forced behavior**: Hooks don't interfere with existing workflows |
|||
- **Local control**: Hooks are installed locally, not globally |
|||
- **Easy removal**: Can be uninstalled at any time |
|||
- **Team flexibility**: Some developers may prefer different tools |
|||
|
|||
## 🌿 Branch Behavior |
|||
|
|||
- **Protected branches** (master, main, production, release, stable): Hook runs automatically |
|||
- **Feature branches**: Hook is skipped, allowing free development with debug code |
|||
|
|||
## 🔍 Debug Patterns Detected |
|||
|
|||
- **Console statements**: `console.log`, `console.debug`, `console.error` |
|||
- **Template debug**: `Debug:`, `debug:` in Vue templates |
|||
- **Debug constants**: `DEBUG_`, `debug_` variables |
|||
- **HTML debug**: `<!-- debug` comments |
|||
- **Debug attributes**: `debug="true"` attributes |
|||
- **Vue debug**: `v-if="debug"`, `v-show="debug"` |
|||
- **Debug TODOs**: `TODO debug`, `FIXME debug` |
|||
|
|||
## 📁 Files Automatically Skipped |
|||
|
|||
- Test files: `*.test.js`, `*.spec.ts`, `*.test.vue` |
|||
- Scripts: `scripts/` directory |
|||
- Test directories: `test-*` directories |
|||
- Documentation: `docs/`, `*.md`, `*.txt` |
|||
- Config files: `*.json`, `*.yml`, `*.yaml` |
|||
- IDE files: `.cursor/` directory |
|||
|
|||
## ✅ Verification |
|||
|
|||
**After installation, verify it's working:** |
|||
|
|||
```bash |
|||
# Check if files exist |
|||
ls -la .git/hooks/pre-commit |
|||
ls -la .git/hooks/debug-checker.config |
|||
|
|||
# Test the hook manually |
|||
.git/hooks/pre-commit |
|||
|
|||
# Test with actual commit |
|||
echo "console.log('test')" > test.vue |
|||
git add test.vue |
|||
git commit -m "test" # Should be blocked |
|||
``` |
|||
|
|||
## 📊 Example Output |
|||
|
|||
``` |
|||
❌ Debug code detected in staged files! |
|||
Branch: master |
|||
Files checked: 1 |
|||
Errors found: 3 |
|||
|
|||
🚨 AccountViewView.vue: Found debug pattern 'console\.' |
|||
🚨 AccountViewView.vue: Found debug pattern 'Debug:' |
|||
🚨 AccountViewView.vue: Found debug pattern 'DEBUG_' |
|||
|
|||
💡 Please remove debug code before committing to master |
|||
``` |
|||
|
|||
## ⚙️ Configuration |
|||
|
|||
Edit `.git/hooks/debug-checker.config` to customize: |
|||
- **Protected branches**: Add/remove branches as needed |
|||
- **Debug patterns**: Customize what gets detected |
|||
- **Skip patterns**: Adjust file filtering rules |
|||
|
|||
## 🚨 Emergency Bypass |
|||
|
|||
If you absolutely need to commit debug code to a protected branch: |
|||
```bash |
|||
git commit --no-verify -m "emergency: debug code needed" |
|||
``` |
|||
⚠️ **Warning**: This bypasses all pre-commit hooks. Use sparingly. |
|||
|
|||
## 🔄 Updates |
|||
|
|||
When the hook is updated in the main repository: |
|||
```bash |
|||
./scripts/install-debug-hook.sh |
|||
``` |
|||
|
|||
## 🚨 Troubleshooting |
|||
|
|||
| Issue | Solution | |
|||
|-------|----------| |
|||
| Hook not running | Check if on protected branch, verify permissions | |
|||
| Permission denied | Run `chmod +x .git/hooks/pre-commit` | |
|||
| Files not found | Ensure you're copying from TimeSafari repo | |
|||
| False positives | Edit `debug-checker.config` to customize patterns | |
|||
|
|||
## 🧪 Testing |
|||
|
|||
A test script is available at `scripts/test-debug-hook.sh` to verify the hook works correctly. |
|||
|
|||
## 💡 Best Practices |
|||
|
|||
1. **Use feature branches** for development with debug code |
|||
2. **Use proper logging** instead of console statements (`logger.info`, `logger.debug`) |
|||
3. **Test thoroughly** before merging to protected branches |
|||
4. **Review commits** to ensure no debug code slips through |
|||
5. **Keep hooks updated** across all repositories |
|||
|
|||
## 📚 Additional Resources |
|||
|
|||
- **Hook documentation**: `scripts/git-hooks/README.md` |
|||
- **Configuration**: `scripts/git-hooks/debug-checker.config` |
|||
- **Test script**: `scripts/test-debug-hook.sh` |
|||
- **Installation script**: `scripts/install-debug-hook.sh` |
|||
|
|||
## 🎯 Team Workflow |
|||
|
|||
**Recommended setup:** |
|||
1. **Repository setup**: Include hook files in `.githooks/` directory |
|||
2. **Team onboarding**: Run installation script in each repo |
|||
3. **Updates**: Re-run installation script when hooks are updated |
|||
4. **Documentation**: Keep this guide updated |
|||
|
|||
--- |
|||
|
|||
**Status**: Active and enforced |
|||
**Last Updated**: 2025-01-27 |
|||
**Maintainer**: Matthew Raymer |
|||
@ -0,0 +1,103 @@ |
|||
# TimeSafari Git Hooks |
|||
|
|||
This directory contains custom Git hooks for the TimeSafari project. |
|||
|
|||
## Debug Code Checker Hook |
|||
|
|||
### Overview |
|||
The `pre-commit` hook automatically checks for debug code when committing to protected branches (master, main, production, release). This prevents debug statements from accidentally reaching production code. |
|||
|
|||
### How It Works |
|||
1. **Branch Detection**: Only runs on protected branches (configurable) |
|||
2. **File Filtering**: Automatically skips test files, scripts, and documentation |
|||
3. **Pattern Matching**: Detects common debug patterns using regex |
|||
4. **Commit Prevention**: Blocks commits containing debug code |
|||
|
|||
### Protected Branches (Default) |
|||
- `master` |
|||
- `main` |
|||
- `production` |
|||
- `release` |
|||
- `stable` |
|||
|
|||
### Debug Patterns Detected |
|||
- **Console statements**: `console.log`, `console.debug`, `console.error` |
|||
- **Template debug**: `Debug:`, `debug:` in Vue templates |
|||
- **Debug constants**: `DEBUG_`, `debug_` variables |
|||
- **HTML debug**: `<!-- debug` comments |
|||
- **Debug attributes**: `debug="true"` attributes |
|||
- **Vue debug**: `v-if="debug"`, `v-show="debug"` |
|||
- **Debug TODOs**: `TODO debug`, `FIXME debug` |
|||
|
|||
### Files Automatically Skipped |
|||
- Test files: `*.test.js`, `*.spec.ts`, `*.test.vue` |
|||
- Scripts: `scripts/` directory |
|||
- Test directories: `test-*` directories |
|||
- Documentation: `docs/`, `*.md`, `*.txt` |
|||
- Config files: `*.json`, `*.yml`, `*.yaml` |
|||
- IDE files: `.cursor/` directory |
|||
|
|||
### Configuration |
|||
Edit `.git/hooks/debug-checker.config` to customize: |
|||
- Protected branches |
|||
- Debug patterns |
|||
- Skip patterns |
|||
- Logging level |
|||
|
|||
### Testing the Hook |
|||
Run the test script to verify the hook works: |
|||
```bash |
|||
./scripts/test-debug-hook.sh |
|||
``` |
|||
|
|||
### Manual Testing |
|||
1. Make changes to a file with debug code |
|||
2. Stage the file: `git add <filename>` |
|||
3. Try to commit: `git commit -m 'test'` |
|||
4. Hook should prevent commit if debug code is found |
|||
|
|||
### Bypassing the Hook (Emergency) |
|||
If you absolutely need to commit debug code to a protected branch: |
|||
```bash |
|||
git commit --no-verify -m "emergency: debug code needed" |
|||
``` |
|||
⚠️ **Warning**: This bypasses all pre-commit hooks. Use sparingly and only in emergencies. |
|||
|
|||
### Troubleshooting |
|||
|
|||
#### Hook not running |
|||
- Ensure the hook is executable: `chmod +x .git/hooks/pre-commit` |
|||
- Check if you're on a protected branch |
|||
- Verify the hook file exists and has correct permissions |
|||
|
|||
#### False positives |
|||
- Add legitimate debug patterns to skip patterns in config |
|||
- Use proper logging levels (`logger.info`, `logger.debug`) instead of console |
|||
- Move debug code to feature branches first |
|||
|
|||
#### Hook too strict |
|||
- Modify debug patterns in config file |
|||
- Add more file types to skip patterns |
|||
- Adjust protected branch list |
|||
|
|||
### Best Practices |
|||
1. **Use feature branches** for development with debug code |
|||
2. **Use proper logging** instead of console statements |
|||
3. **Test thoroughly** before merging to protected branches |
|||
4. **Review commits** to ensure no debug code slips through |
|||
5. **Keep config updated** as project needs change |
|||
|
|||
### Integration with CI/CD |
|||
This hook works locally. For CI/CD pipelines, consider: |
|||
- Running the same checks in your build process |
|||
- Adding ESLint rules for console statements |
|||
- Using TypeScript strict mode |
|||
- Adding debug code detection to PR checks |
|||
|
|||
### Support |
|||
If you encounter issues: |
|||
1. Check the hook output for specific error messages |
|||
2. Verify your branch is in the protected list |
|||
3. Review the configuration file |
|||
4. Test with the provided test script |
|||
5. Check file permissions and git setup |
|||
@ -0,0 +1,86 @@ |
|||
# TimeSafari Debug Checker Configuration |
|||
# Edit this file to customize protected branches and debug patterns |
|||
|
|||
# Protected branches where debug code checking is enforced |
|||
# Add or remove branches as needed |
|||
PROTECTED_BRANCHES=( |
|||
"master" |
|||
"main" |
|||
"production" |
|||
"release" |
|||
"stable" |
|||
) |
|||
|
|||
# Debug patterns to detect (regex patterns) |
|||
# Add or remove patterns as needed |
|||
DEBUG_PATTERNS=( |
|||
# Console statements |
|||
"console\." |
|||
|
|||
# Template debug text |
|||
"Debug:" |
|||
"debug:" |
|||
|
|||
# Debug constants and variables |
|||
"DEBUG_" |
|||
"debug_" |
|||
|
|||
# HTML debug comments |
|||
"<!-- debug" |
|||
|
|||
# Debug attributes |
|||
"debug.*=" |
|||
|
|||
# Vue debug patterns |
|||
"v-if.*debug" |
|||
"v-show.*debug" |
|||
|
|||
# Common debug text |
|||
"TODO.*debug" |
|||
"FIXME.*debug" |
|||
|
|||
# Debug imports (uncomment if you want to catch these) |
|||
# "import.*debug" |
|||
# "require.*debug" |
|||
) |
|||
|
|||
# Files and directories to skip during checking |
|||
# Add patterns to exclude from debug checking |
|||
SKIP_PATTERNS=( |
|||
"\.(test|spec)\.(js|ts|vue)$" # Test files (must have .test. or .spec.) |
|||
"^scripts/" # Scripts directory |
|||
"^test-.*/" # Test directories (must end with /) |
|||
"^\.git/" # Git directory |
|||
"^node_modules/" # Dependencies |
|||
"^docs/" # Documentation |
|||
"^\.cursor/" # Cursor IDE files |
|||
"\.md$" # Markdown files |
|||
"\.txt$" # Text files |
|||
"\.json$" # JSON config files |
|||
"\.yml$" # YAML config files |
|||
"\.yaml$" # YAML config files |
|||
) |
|||
|
|||
# Files that are whitelisted for console statements |
|||
# These files may contain intentional console.log statements that are |
|||
# properly whitelisted with eslint-disable-next-line no-console comments |
|||
WHITELIST_FILES=( |
|||
"src/services/platforms/WebPlatformService.ts" # Worker context logging |
|||
"src/services/platforms/CapacitorPlatformService.ts" # Platform-specific logging |
|||
"src/services/platforms/ElectronPlatformService.ts" # Electron-specific logging |
|||
"src/services/QRScanner/.*" # QR Scanner services |
|||
"src/utils/logger.ts" # Logger utility itself |
|||
"src/utils/LogCollector.ts" # Log collection utilities |
|||
"scripts/.*" # Build and utility scripts |
|||
"test-.*/.*" # Test directories |
|||
".*\.test\..*" # Test files |
|||
".*\.spec\..*" # Spec files |
|||
) |
|||
|
|||
# Logging level (debug, info, warn, error) |
|||
LOG_LEVEL="info" |
|||
|
|||
# Exit codes |
|||
EXIT_SUCCESS=0 |
|||
EXIT_DEBUG_FOUND=1 |
|||
EXIT_ERROR=2 |
|||
@ -0,0 +1,252 @@ |
|||
#!/bin/bash |
|||
|
|||
# TimeSafari Pre-commit Hook - Debug Code Checker |
|||
# Only runs on master or specified branches to catch debug code before it reaches production |
|||
|
|||
# Hook directory |
|||
HOOK_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)" |
|||
CONFIG_FILE="$HOOK_DIR/debug-checker.config" |
|||
|
|||
# Default configuration (fallback if config file is missing) |
|||
DEFAULT_PROTECTED_BRANCHES=("master" "main" "production" "release") |
|||
DEFAULT_DEBUG_PATTERNS=( |
|||
"console\." |
|||
"Debug:" |
|||
"debug:" |
|||
"DEBUG_" |
|||
"debug_" |
|||
"<!-- debug" |
|||
"debug.*=" |
|||
) |
|||
DEFAULT_WHITELIST_FILES=( |
|||
"src/services/platforms/WebPlatformService.ts" |
|||
"src/services/platforms/CapacitorPlatformService.ts" |
|||
"src/services/platforms/ElectronPlatformService.ts" |
|||
) |
|||
|
|||
# Load configuration from file if it exists |
|||
load_config() { |
|||
if [[ -f "$CONFIG_FILE" ]]; then |
|||
# Source the config file to load variables |
|||
# We'll use a safer approach by reading and parsing |
|||
PROTECTED_BRANCHES=() |
|||
DEBUG_PATTERNS=() |
|||
SKIP_PATTERNS=() |
|||
WHITELIST_FILES=() |
|||
|
|||
# Read protected branches |
|||
while IFS= read -r line; do |
|||
if [[ "$line" =~ ^PROTECTED_BRANCHES=\( ]]; then |
|||
# Start reading array |
|||
while IFS= read -r line; do |
|||
if [[ "$line" =~ ^\)$ ]]; then |
|||
break |
|||
fi |
|||
if [[ "$line" =~ \"([^\"]+)\" ]]; then |
|||
PROTECTED_BRANCHES+=("${BASH_REMATCH[1]}") |
|||
fi |
|||
done |
|||
fi |
|||
done < "$CONFIG_FILE" |
|||
|
|||
# Read debug patterns |
|||
while IFS= read -r line; do |
|||
if [[ "$line" =~ ^DEBUG_PATTERNS=\( ]]; then |
|||
while IFS= read -r line; do |
|||
if [[ "$line" =~ ^\)$ ]]; then |
|||
break |
|||
fi |
|||
if [[ "$line" =~ \"([^\"]+)\" ]]; then |
|||
DEBUG_PATTERNS+=("${BASH_REMATCH[1]}") |
|||
fi |
|||
done |
|||
fi |
|||
done < "$CONFIG_FILE" |
|||
|
|||
# Read skip patterns |
|||
while IFS= read -r line; do |
|||
if [[ "$line" =~ ^SKIP_PATTERNS=\( ]]; then |
|||
while IFS= read -r line; do |
|||
if [[ "$line" =~ ^\)$ ]]; then |
|||
break |
|||
fi |
|||
if [[ "$line" =~ \"([^\"]+)\" ]]; then |
|||
SKIP_PATTERNS+=("${BASH_REMATCH[1]}") |
|||
fi |
|||
done |
|||
fi |
|||
done < "$CONFIG_FILE" |
|||
|
|||
# Read whitelist files |
|||
while IFS= read -r line; do |
|||
if [[ "$line" =~ ^WHITELIST_FILES=\( ]]; then |
|||
while IFS= read -r line; do |
|||
if [[ "$line" =~ ^\)$ ]]; then |
|||
break |
|||
fi |
|||
if [[ "$line" =~ \"([^\"]+)\" ]]; then |
|||
WHITELIST_FILES+=("${BASH_REMATCH[1]}") |
|||
fi |
|||
done |
|||
fi |
|||
done < "$CONFIG_FILE" |
|||
fi |
|||
|
|||
# Use defaults if config loading failed |
|||
if [[ ${#PROTECTED_BRANCHES[@]} -eq 0 ]]; then |
|||
PROTECTED_BRANCHES=("${DEFAULT_PROTECTED_BRANCHES[@]}") |
|||
fi |
|||
|
|||
if [[ ${#DEBUG_PATTERNS[@]} -eq 0 ]]; then |
|||
DEBUG_PATTERNS=("${DEFAULT_DEBUG_PATTERNS[@]}") |
|||
fi |
|||
|
|||
if [[ ${#SKIP_PATTERNS[@]} -eq 0 ]]; then |
|||
SKIP_PATTERNS=("${DEFAULT_SKIP_PATTERNS[@]}") |
|||
fi |
|||
|
|||
if [[ ${#WHITELIST_FILES[@]} -eq 0 ]]; then |
|||
WHITELIST_FILES=("${DEFAULT_WHITELIST_FILES[@]}") |
|||
fi |
|||
|
|||
} |
|||
|
|||
# Check if current branch is protected |
|||
is_protected_branch() { |
|||
local branch="$1" |
|||
for protected in "${PROTECTED_BRANCHES[@]}"; do |
|||
if [[ "$branch" == "$protected" ]]; then |
|||
return 0 |
|||
fi |
|||
done |
|||
return 1 |
|||
} |
|||
|
|||
# Check if file should be skipped |
|||
should_skip_file() { |
|||
local file="$1" |
|||
for pattern in "${SKIP_PATTERNS[@]}"; do |
|||
if [[ "$file" =~ $pattern ]]; then |
|||
return 0 |
|||
fi |
|||
done |
|||
return 1 |
|||
} |
|||
|
|||
# Check if file is whitelisted for console statements |
|||
is_whitelisted_file() { |
|||
local file="$1" |
|||
for whitelisted in "${WHITELIST_FILES[@]}"; do |
|||
if [[ "$file" =~ $whitelisted ]]; then |
|||
return 0 |
|||
fi |
|||
done |
|||
return 1 |
|||
} |
|||
|
|||
# Main execution |
|||
main() { |
|||
# Load configuration |
|||
load_config |
|||
|
|||
# Get current branch name |
|||
CURRENT_BRANCH=$(git symbolic-ref --short HEAD 2>/dev/null) |
|||
|
|||
if [[ -z "$CURRENT_BRANCH" ]]; then |
|||
echo "⚠️ Could not determine current branch, skipping debug check" |
|||
exit 0 |
|||
fi |
|||
|
|||
# Check if we should run the hook |
|||
if ! is_protected_branch "$CURRENT_BRANCH"; then |
|||
echo "🔒 Pre-commit hook skipped - not on protected branch ($CURRENT_BRANCH)" |
|||
echo " Protected branches: ${PROTECTED_BRANCHES[*]}" |
|||
exit 0 |
|||
fi |
|||
|
|||
echo "🔍 Running debug code check on protected branch: $CURRENT_BRANCH" |
|||
echo " Using config: $CONFIG_FILE" |
|||
|
|||
# Get all staged files (modified, added, copied, merged) |
|||
ALL_STAGED_FILES=$(git diff --cached --name-only) |
|||
|
|||
|
|||
|
|||
if [ -z "$ALL_STAGED_FILES" ]; then |
|||
echo "✅ No staged files to check" |
|||
exit 0 |
|||
fi |
|||
|
|||
# Initialize error tracking |
|||
ERRORS_FOUND=0 |
|||
ERROR_MESSAGES=() |
|||
FILES_CHECKED=0 |
|||
|
|||
# Check each staged file for debug patterns |
|||
for file in $ALL_STAGED_FILES; do |
|||
# Skip files that should be ignored |
|||
if should_skip_file "$file"; then |
|||
continue |
|||
fi |
|||
|
|||
FILES_CHECKED=$((FILES_CHECKED + 1)) |
|||
|
|||
# Check for debug patterns in the file |
|||
for pattern in "${DEBUG_PATTERNS[@]}"; do |
|||
# Skip console pattern checks for whitelisted files |
|||
if [[ "$pattern" == "console\." ]] && is_whitelisted_file "$file"; then |
|||
continue |
|||
fi |
|||
|
|||
# For new files, check the file content directly |
|||
# For modified files, check the staged diff |
|||
if [[ -f "$file" ]]; then |
|||
# New file - check content directly |
|||
if grep -E "$pattern" "$file" > /dev/null; then |
|||
ERRORS_FOUND=$((ERRORS_FOUND + 1)) |
|||
ERROR_MESSAGES+=("🚨 $file: Found debug pattern '$pattern'") |
|||
fi |
|||
else |
|||
# Modified file - check staged diff |
|||
if git diff --cached "$file" | grep -E "$pattern" > /dev/null; then |
|||
ERRORS_FOUND=$((ERRORS_FOUND + 1)) |
|||
ERROR_MESSAGES+=("🚨 $file: Found debug pattern '$pattern'") |
|||
fi |
|||
fi |
|||
done |
|||
done |
|||
|
|||
# Report results |
|||
if [ $ERRORS_FOUND -gt 0 ]; then |
|||
echo "" |
|||
echo "❌ Debug code detected in staged files!" |
|||
echo " Branch: $CURRENT_BRANCH" |
|||
echo " Files checked: $FILES_CHECKED" |
|||
echo " Errors found: $ERRORS_FOUND" |
|||
echo "" |
|||
for msg in "${ERROR_MESSAGES[@]}"; do |
|||
echo " $msg" |
|||
done |
|||
echo "" |
|||
echo "💡 Please remove debug code before committing to $CURRENT_BRANCH" |
|||
echo " Common debug patterns to check:" |
|||
echo " - console.log, console.debug, console.error" |
|||
echo " - Debug: or debug: in templates" |
|||
echo " - DEBUG_ constants" |
|||
echo " - HTML comments with debug" |
|||
echo "" |
|||
echo " If debug code is intentional, consider:" |
|||
echo " - Moving to a feature branch first" |
|||
echo " - Using proper logging levels (logger.info, logger.debug)" |
|||
echo " - Adding debug code to .gitignore or .debugignore" |
|||
echo "" |
|||
echo " Configuration file: $CONFIG_FILE" |
|||
exit 1 |
|||
else |
|||
echo "✅ No debug code found in $FILES_CHECKED staged files" |
|||
exit 0 |
|||
fi |
|||
} |
|||
|
|||
# Run main function |
|||
main "$@" |
|||
@ -0,0 +1,171 @@ |
|||
#!/bin/bash |
|||
|
|||
# TimeSafari Debug Hook Installer |
|||
# Run this script in any repository to install the debug pre-commit hook |
|||
|
|||
set -e |
|||
|
|||
# Colors for output |
|||
RED='\033[0;31m' |
|||
GREEN='\033[0;32m' |
|||
YELLOW='\033[1;33m' |
|||
BLUE='\033[0;34m' |
|||
NC='\033[0m' # No Color |
|||
|
|||
echo -e "${BLUE}🔧 TimeSafari Debug Hook Installer${NC}" |
|||
echo "=============================================" |
|||
|
|||
# Check if we're in a git repository |
|||
if ! git rev-parse --git-dir > /dev/null 2>&1; then |
|||
echo -e "${RED}❌ Error: Not in a git repository${NC}" |
|||
echo "Please run this script from within a git repository" |
|||
exit 1 |
|||
fi |
|||
|
|||
# Get repository root |
|||
REPO_ROOT=$(git rev-parse --show-toplevel) |
|||
HOOKS_DIR="$REPO_ROOT/.git/hooks" |
|||
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)" |
|||
|
|||
echo -e "${BLUE}Repository:${NC} $REPO_ROOT" |
|||
echo -e "${BLUE}Hooks directory:${NC} $HOOKS_DIR" |
|||
echo -e "${BLUE}Script directory:${NC} $SCRIPT_DIR" |
|||
|
|||
# Check if hooks directory exists |
|||
if [[ ! -d "$HOOKS_DIR" ]]; then |
|||
echo -e "${RED}❌ Error: Hooks directory not found${NC}" |
|||
echo "This repository may not be properly initialized" |
|||
exit 1 |
|||
fi |
|||
|
|||
# Check if we have the hook files in the repository |
|||
HOOK_SCRIPT="$SCRIPT_DIR/git-hooks/pre-commit" |
|||
CONFIG_FILE="$SCRIPT_DIR/git-hooks/debug-checker.config" |
|||
|
|||
if [[ ! -f "$HOOK_SCRIPT" ]]; then |
|||
echo -e "${RED}❌ Error: Pre-commit hook script not found${NC}" |
|||
echo "Expected location: $HOOK_SCRIPT" |
|||
echo "Make sure you're running this from the TimeSafari repository" |
|||
exit 1 |
|||
fi |
|||
|
|||
if [[ ! -f "$CONFIG_FILE" ]]; then |
|||
echo -e "${RED}❌ Error: Debug checker config not found${NC}" |
|||
echo "Expected location: $CONFIG_FILE" |
|||
echo "Make sure you're running this from the TimeSafari repository" |
|||
exit 1 |
|||
fi |
|||
|
|||
# Check if already installed |
|||
if [[ -f "$HOOKS_DIR/pre-commit" && -f "$HOOKS_DIR/debug-checker.config" ]]; then |
|||
echo -e "${YELLOW}⚠️ Debug hook already appears to be installed${NC}" |
|||
echo -e " Checking if update is needed..." |
|||
|
|||
# Check if files are different |
|||
if diff "$HOOK_SCRIPT" "$HOOKS_DIR/pre-commit" > /dev/null 2>&1; then |
|||
echo -e " ${GREEN}✅${NC} Hook script is up to date" |
|||
HOOK_UP_TO_DATE=true |
|||
else |
|||
echo -e " ${YELLOW}⚠️ Hook script differs - will update${NC}" |
|||
HOOK_UP_TO_DATE=false |
|||
fi |
|||
|
|||
if diff "$CONFIG_FILE" "$HOOKS_DIR/debug-checker.config" > /dev/null 2>&1; then |
|||
echo -e " ${GREEN}✅${NC} Config file is up to date" |
|||
CONFIG_UP_TO_DATE=true |
|||
else |
|||
echo -e " ${YELLOW}⚠️ Config file differs - will update${NC}" |
|||
CONFIG_UP_TO_DATE=false |
|||
fi |
|||
|
|||
if [[ "$HOOK_UP_TO_DATE" == true && "$CONFIG_UP_TO_DATE" == true ]]; then |
|||
echo -e "\n${GREEN}✅ Debug hook is already up to date!${NC}" |
|||
echo -e " No installation needed" |
|||
else |
|||
echo -e "\n${BLUE}Updating existing installation...${NC}" |
|||
fi |
|||
else |
|||
echo -e "\n${BLUE}Installing debug hook...${NC}" |
|||
fi |
|||
|
|||
# Copy/update the hook script if needed |
|||
if [[ "$HOOK_UP_TO_DATE" != true ]]; then |
|||
cp "$HOOK_SCRIPT" "$HOOKS_DIR/pre-commit" |
|||
chmod +x "$HOOKS_DIR/pre-commit" |
|||
echo -e " ${GREEN}✅${NC} Pre-commit hook installed/updated" |
|||
fi |
|||
|
|||
# Copy/update the config file if needed |
|||
if [[ "$CONFIG_UP_TO_DATE" != true ]]; then |
|||
cp "$CONFIG_FILE" "$HOOKS_DIR/debug-checker.config" |
|||
echo -e " ${GREEN}✅${NC} Configuration file installed/updated" |
|||
fi |
|||
|
|||
# Copy/update the README if needed |
|||
README_FILE="$SCRIPT_DIR/git-hooks/README.md" |
|||
if [[ -f "$README_FILE" ]]; then |
|||
if [[ ! -f "$HOOKS_DIR/README.md" ]] || ! diff "$README_FILE" "$HOOKS_DIR/README.md" > /dev/null 2>&1; then |
|||
cp "$README_FILE" "$HOOKS_DIR/README.md" |
|||
echo -e " ${GREEN}✅${NC} Documentation installed/updated" |
|||
else |
|||
echo -e " ${GREEN}✅${NC} Documentation is up to date" |
|||
fi |
|||
fi |
|||
|
|||
echo -e "\n${GREEN}🎉 Debug hook installation complete!${NC}" |
|||
|
|||
# Test the installation |
|||
echo -e "\n${BLUE}Testing installation...${NC}" |
|||
if [[ -x "$HOOKS_DIR/pre-commit" ]]; then |
|||
echo -e " ${GREEN}✅${NC} Hook is executable" |
|||
else |
|||
echo -e " ${RED}❌${NC} Hook is not executable" |
|||
fi |
|||
|
|||
if [[ -f "$HOOKS_DIR/debug-checker.config" ]]; then |
|||
echo -e " ${GREEN}✅${NC} Config file exists" |
|||
else |
|||
echo -e " ${RED}❌${NC} Config file missing" |
|||
fi |
|||
|
|||
# Show current branch status |
|||
CURRENT_BRANCH=$(git symbolic-ref --short HEAD 2>/dev/null || echo "detached") |
|||
echo -e "\n${BLUE}Current branch:${NC} $CURRENT_BRANCH" |
|||
|
|||
# Check if this is a protected branch |
|||
PROTECTED_BRANCHES=("master" "main" "production" "release" "stable") |
|||
IS_PROTECTED=false |
|||
|
|||
for branch in "${PROTECTED_BRANCHES[@]}"; do |
|||
if [[ "$CURRENT_BRANCH" == "$branch" ]]; then |
|||
IS_PROTECTED=true |
|||
break |
|||
fi |
|||
done |
|||
|
|||
if [[ "$IS_PROTECTED" == true ]]; then |
|||
echo -e "${YELLOW}⚠️ You're on a protected branch ($CURRENT_BRANCH)${NC}" |
|||
echo -e " The debug hook will now run on all commits to this branch" |
|||
echo -e " Consider switching to a feature branch for development" |
|||
else |
|||
echo -e "${GREEN}✅ You're on a feature branch ($CURRENT_BRANCH)${NC}" |
|||
echo -e " The debug hook will be skipped on this branch" |
|||
echo -e " You can develop with debug code freely" |
|||
fi |
|||
|
|||
echo -e "\n${BLUE}Next steps:${NC}" |
|||
echo "1. The hook will now run automatically on protected branches" |
|||
echo "2. Test it by trying to commit a file with debug code" |
|||
echo "3. Use feature branches for development with debug code" |
|||
echo "4. Check the README.md in .git/hooks/ for more information" |
|||
|
|||
echo -e "\n${BLUE}To test the hook:${NC}" |
|||
echo "1. Create a test file with debug code (e.g., console.log('test'))" |
|||
echo "2. Stage it: git add <filename>" |
|||
echo "3. Try to commit: git commit -m 'test'" |
|||
echo "4. The hook should prevent the commit if debug code is found" |
|||
|
|||
echo -e "\n${BLUE}To uninstall:${NC}" |
|||
echo "rm $HOOKS_DIR/pre-commit" |
|||
echo "rm $HOOKS_DIR/debug-checker.config" |
|||
echo "rm $HOOKS_DIR/README.md" |
|||
@ -0,0 +1,117 @@ |
|||
#!/bin/bash |
|||
|
|||
# Test script for the debug pre-commit hook |
|||
# This script helps verify that the hook is working correctly |
|||
|
|||
set -e |
|||
|
|||
echo "🧪 Testing TimeSafari Debug Pre-commit Hook" |
|||
echo "=============================================" |
|||
|
|||
# Colors for output |
|||
RED='\033[0;31m' |
|||
GREEN='\033[0;32m' |
|||
YELLOW='\033[1;33m' |
|||
BLUE='\033[0;34m' |
|||
NC='\033[0m' # No Color |
|||
|
|||
# Test directory |
|||
TEST_DIR="$(mktemp -d)" |
|||
echo -e "${BLUE}Created test directory: $TEST_DIR${NC}" |
|||
|
|||
# Function to cleanup |
|||
cleanup() { |
|||
echo -e "${YELLOW}Cleaning up test directory...${NC}" |
|||
rm -rf "$TEST_DIR" |
|||
} |
|||
|
|||
# Set trap to cleanup on exit |
|||
trap cleanup EXIT |
|||
|
|||
# Function to run test |
|||
run_test() { |
|||
local test_name="$1" |
|||
local test_file="$2" |
|||
local expected_exit="$3" |
|||
|
|||
echo -e "\n${BLUE}Running test: $test_name${NC}" |
|||
|
|||
# Create test file |
|||
echo "$test_file" > "$TEST_DIR/test.vue" |
|||
|
|||
# Stage the file |
|||
cd "$TEST_DIR" |
|||
git init > /dev/null 2>&1 |
|||
git add test.vue > /dev/null 2>&1 |
|||
|
|||
# Run the hook |
|||
if bash ../../.git/hooks/pre-commit > hook_output.txt 2>&1; then |
|||
exit_code=0 |
|||
else |
|||
exit_code=$? |
|||
fi |
|||
|
|||
# Check result |
|||
if [[ $exit_code -eq $expected_exit ]]; then |
|||
echo -e " ${GREEN}✅ PASS${NC} - Exit code: $exit_code (expected: $expected_exit)" |
|||
else |
|||
echo -e " ${RED}❌ FAIL${NC} - Exit code: $exit_code (expected: $expected_exit)" |
|||
echo -e " ${YELLOW}Hook output:${NC}" |
|||
cat hook_output.txt |
|||
fi |
|||
|
|||
# Cleanup git |
|||
rm -rf .git |
|||
rm -f hook_output.txt |
|||
} |
|||
|
|||
# Test cases |
|||
echo -e "\n${BLUE}Test Case 1: Clean file (should pass)${NC}" |
|||
run_test "Clean file" "// No debug code here" 0 |
|||
|
|||
echo -e "\n${BLUE}Test Case 2: Console statement (should fail)${NC}" |
|||
run_test "Console statement" "console.log('debug info')" 1 |
|||
|
|||
echo -e "\n${BLUE}Test Case 3: Debug template (should fail)${NC}" |
|||
run_test "Debug template" "Debug: {{ isMapReady ? 'Map Ready' : 'Map Loading' }}" 1 |
|||
|
|||
echo -e "\n${BLUE}Test Case 4: Debug constant (should fail)${NC}" |
|||
run_test "Debug constant" "const DEBUG_MODE = true" 1 |
|||
|
|||
echo -e "\n${BLUE}Test Case 5: Mixed content (should fail)${NC}" |
|||
run_test "Mixed content" "// Some normal code\nconsole.debug('test')\n// More normal code" 1 |
|||
|
|||
echo -e "\n${BLUE}Test Case 6: HTML debug comment (should fail)${NC}" |
|||
run_test "HTML debug comment" "<!-- debug: this is debug info -->" 1 |
|||
|
|||
echo -e "\n${BLUE}Test Case 7: Debug attribute (should fail)${NC}" |
|||
run_test "Debug attribute" "<div debug='true'>content</div>" 1 |
|||
|
|||
echo -e "\n${BLUE}Test Case 8: Test file (should be skipped)${NC}" |
|||
run_test "Test file" "console.log('this should be skipped')" 0 |
|||
|
|||
# Test branch detection |
|||
echo -e "\n${BLUE}Testing branch detection...${NC}" |
|||
cd "$TEST_DIR" |
|||
git init > /dev/null 2>&1 |
|||
git checkout -b feature-branch > /dev/null 2>&1 |
|||
echo "console.log('debug')" > test.vue |
|||
git add test.vue > /dev/null 2>&1 |
|||
|
|||
if bash ../../.git/hooks/pre-commit > hook_output.txt 2>&1; then |
|||
echo -e " ${GREEN}✅ PASS${NC} - Hook skipped on feature branch" |
|||
else |
|||
echo -e " ${RED}❌ FAIL${NC} - Hook should have been skipped on feature branch" |
|||
echo -e " ${YELLOW}Hook output:${NC}" |
|||
cat hook_output.txt |
|||
fi |
|||
|
|||
rm -rf .git |
|||
rm -f hook_output.txt |
|||
|
|||
echo -e "\n${GREEN}🎉 All tests completed!${NC}" |
|||
echo -e "\n${BLUE}To test manually:${NC}" |
|||
echo "1. Make changes to a file with debug code" |
|||
echo "2. Stage the file: git add <filename>" |
|||
echo "3. Try to commit: git commit -m 'test'" |
|||
echo "4. The hook should prevent the commit if debug code is found" |
|||
Loading…
Reference in new issue