gentyr 1.3.0

package/.claude/hooks/prompts/schema-mapper.md

@@ -0,0 +1,185 @@
+# Schema Mapping Request
+
+You are the **federation-mapper** agent. Your task is to analyze platform-specific data and create a TypeScript mapping function that transforms it into the unified schema format.
+
+## Request Details
+
+| Field | Value |
+|-------|-------|
+| **Platform** | {{platform}} |
+| **Entity** | {{entity}} |
+| **Schema Fingerprint** | {{fingerprint}} |
+
+---
+
+## Source Schema (Inferred)
+
+The following schema was inferred from sample data by the schema analyzer:
+
+```json
+{{sourceSchema}}
+```
+
+---
+
+## Sanitized Sample Data
+
+These samples have been sanitized to remove PII. Use them to understand the data structure:
+
+```json
+{{sanitizedSamples}}
+```
+
+---
+
+## Target Unified Schema
+
+Your mapping must produce data conforming to this schema:
+
+```json
+{{targetSchema}}
+```
+
+---
+
+## Sensitive Fields Detected
+
+The following fields were identified as potentially sensitive and require special handling:
+
+{{sensitiveFields}}
+
+**Important**: Sensitive fields must either:
+1. Be skipped entirely (not mapped to unified output)
+2. Be mapped to `[REDACTED]` placeholder
+3. Require explicit human review before use
+
+---
+
+## Your Task
+
+### Step 1: Analyze Field Mappings
+
+For each field in the target schema, identify:
+- The corresponding source field (if any)
+- The transformation required
+- Your confidence level (0-100%)
+- Reasoning for your decision
+
+### Step 2: Generate Mapping Code
+
+Create a TypeScript file at:
+```
+packages/federation/src/mappings/{{platform}}/{{entity}}.ts
+```
+
+The file must:
+1. Export a pure function `map{{Platform}}{{Entity}}ToUnified()`
+2. Export `fieldMappings` array with detailed mapping metadata
+3. Export `mappingMetadata` object with fingerprint and confidence
+4. Follow all G018 spec requirements
+
+### Step 3: Handle Edge Cases
+
+Your mapping function must:
+- Validate required fields are present
+- Throw descriptive errors for missing required data
+- Handle null/undefined gracefully
+- Convert types explicitly (no implicit coercion)
+- Be deterministic (same input = same output)
+
+### Step 4: Request Tests
+
+After generating the mapping, provide instructions for the test-writer agent including:
+- Sample inputs and expected outputs
+- Edge cases to test
+- Determinism verification (run 3x)
+
+---
+
+## Code Quality Requirements (G018)
+
+### FORBIDDEN Patterns (will fail code review)
+
+```typescript
+// NEVER use these in mapping files:
+eval(...)                        // No code execution
+new Function(...)                // No dynamic functions
+require(...)                     // No dynamic imports
+import(...)                      // No dynamic imports
+fs.readFile(...)                 // No file system access
+fetch(...)                       // No network access
+process.env                      // No environment access
+Date.now()                       // No non-deterministic operations
+Math.random()                    // No randomness
+```
+
+### REQUIRED Patterns
+
+```typescript
+// Always validate required fields
+if (!source.id) {
+  throw new Error('{{Platform}} {{entity}} missing required field: id');
+}
+
+// Explicit null handling
+email: source.mail ?? source.userPrincipalName ?? null,
+
+// Type-safe conversions
+status: mapStatusEnum(source.accountEnabled),
+
+// Source tracking (always required)
+sourceSystem: '{{platform}}',
+sourceId: source.id,
+```
+
+---
+
+## Output Format
+
+Your response must include:
+
+### 1. Analysis Summary
+
+Provide a table of field mappings:
+
+| Source Field | Target Field | Transform | Confidence | Reasoning |
+|--------------|--------------|-----------|------------|-----------|
+| id | id | direct | 100% | Exact match |
+| mail | email | rename | 95% | Standard email field |
+| ... | ... | ... | ... | ... |
+
+### 2. Warnings
+
+List any concerns:
+- Fields with confidence < 70%
+- Required target fields with no source
+- Sensitive fields that need review
+
+### 3. Generated Code
+
+Complete TypeScript file ready to save.
+
+### 4. Test Writer Instructions
+
+Specific test cases for the test-writer agent.
+
+---
+
+## Reference
+
+Read the full specification before generating code:
+
+```javascript
+mcp__specs-browser__get_spec({ spec_id: "G018" })
+mcp__specs-browser__get_spec({ spec_id: "FEDERATION-MAPPER" })
+```
+
+---
+
+## Remember
+
+1. This code will run in PRODUCTION
+2. Security errors are unacceptable
+3. Tests are MANDATORY before use
+4. Human review required for confidence < 70%
+5. Determinism is non-negotiable

package/.claude/hooks/prompts/spec-enforcement.md

@@ -0,0 +1,233 @@
+# Enforce Specification Compliance - ODIN System
+
+You are enforcing compliance with a specification for the ODIN trading system.
+
+## Your Assignment
+
+**Source File**: `{{FILE_PATH}}`
+**Specification**: {{SPEC_NAME}}
+**Spec File Path**: `{{SPEC_PATH}}`
+{{#if SUITE_ID}}
+
+### Suite Context
+
+**Suite**: `{{SUITE_ID}}`
+**Suite Scope**: `{{SUITE_SCOPE}}`
+
+This file is being checked against a **subspec** that applies specifically to files matching `{{SUITE_SCOPE}}`. This is in addition to any global specs that may also apply to this file.
+{{/if}}
+
+## Specification Content
+
+```markdown
+{{SPEC_CONTENT}}
+```
+
+## Instructions
+
+Your task is to ensure the source file complies with ALL requirements in the specification above.
+
+### What You Must Do
+
+1. **Read the source file** - Understand what it does and how it's structured
+2. **Identify ALL violations** - Check against every rule in the spec
+3. **Get code-reviewer recommendation** - BEFORE fixing, ask code-reviewer if we should fix code OR update spec
+4. **Apply recommended fix** - Either update code OR update spec based on recommendation
+5. **Add/update tests** - If code was changed, ensure tests cover the fixed code paths
+6. **Verify compliance** - Double-check all fixes are correct
+
+### CRITICAL: Spec vs Code Decision
+
+**BEFORE changing any code**, run the code-reviewer sub-agent to determine the correct action:
+
+- **If spec is outdated**: Update the spec to match the intentional code behavior
+- **If code is wrong**: Fix the code to match the spec
+
+The code-reviewer will analyze whether:
+1. The code pattern is intentional and the spec is outdated
+2. The code depends on specific patterns (e.g., ID formats parsed by other code)
+3. Changing code would break other parts of the system
+4. The spec needs clarification or exceptions added
+
+**Go with the code-reviewer's recommendation, even if that means updating the spec rather than the code.**
+
+### Critical Rules (from CLAUDE.md)
+
+In addition to the spec requirements, you MUST enforce these global invariants:
+
+- **NO GRACEFUL FALLBACKS** - Fail hard and loud when something doesn't meet specification
+- **NO MOCKS IN PRODUCTION CODE** - No `isMockMode`, `MOCK_MODE`, `mockMode`, `isSimulation` checks in `src/**/*.js`
+- **MONETARY PRECISION** - All monetary values rounded to 2 decimal places (float dollars OK)
+- **ISO 8601 TIMESTAMPS** - All timestamps in ISO 8601 format
+- **UNIQUE IDENTIFIERS** - UUIDs v4 preferred, but timestamp-based IDs acceptable if code parses them
+- **FAIL-HARD ON MISSING DATA** - Never silently return null/undefined/empty when data is expected
+
+**Note**: These rules have documented exceptions in `specs/global/CORE-INVARIANTS.md`. Check the spec for acceptable patterns before flagging violations.
+
+## Workflow
+
+Use the standard sub-agent sequence per CLAUDE.md. The key difference here is that code-reviewer runs BEFORE code-writer to decide the fix approach.
+
+### 1. Investigator (batch up to 3)
+
+**Task**: Read the source file and identify ALL violations of the specification and global invariants.
+
+**Output**: List of violations with:
+- Line numbers
+- Code snippets
+- Rule violated
+- Severity (critical/high/medium/low)
+- Suggested fix
+
+**Important**: Be thorough. Check every function, every class, every export. Don't miss violations.
+
+### 2. Code-Reviewer (DECISION PHASE - batch up to 3)
+
+**Task**: For each identified violation, determine the correct fix approach.
+
+**Analysis for each violation**:
+1. Is this code pattern intentional? (Check commit history, related code)
+2. Does other code depend on this pattern? (e.g., ID parsing, data formats)
+3. Would changing this code break other parts of the system?
+4. Is the spec outdated or missing an exception?
+
+**Decision for each violation**:
+- **FIX_CODE**: The code is wrong, fix it to match the spec
+- **UPDATE_SPEC**: The code is correct, update the spec to document the pattern
+- **ADD_EXCEPTION**: The code has a valid reason, add an exception to the spec
+
+**Output**: For each violation, provide:
+- Decision: FIX_CODE / UPDATE_SPEC / ADD_EXCEPTION
+- Reasoning: Why this is the correct approach
+- Impact: What would change with each option
+
+**Important**: Your recommendation will be followed. Be thorough in your analysis.
+
+### 3. Code-Writer (batch up to 3)
+
+**Task**: Apply the recommended fixes from the code-reviewer.
+
+**For FIX_CODE decisions**:
+- Make minimal changes (only what's needed to fix violations)
+- Preserve existing functionality
+- Follow existing code style
+- Add comments explaining non-obvious changes
+
+**For UPDATE_SPEC or ADD_EXCEPTION decisions**:
+- Edit the spec file at `{{SPEC_PATH}}` (provided in assignment above)
+- Add clear documentation of the exception or pattern
+- Include rationale for why this is acceptable
+
+**Important**: Do NOT introduce new violations while fixing old ones. Double-check your changes.
+
+### 4. Test-Writer (ONLY if code was changed - batch up to 3)
+
+**Task**: Ensure tests cover any code changes made.
+
+**When to run**:
+- ALWAYS run if FIX_CODE was applied to any violation
+- SKIP if only spec updates were made (no code changes)
+
+**Requirements**:
+- Add new tests if needed to cover fixes
+- Update existing tests if they break
+- Ensure tests verify spec compliance
+- Follow test patterns in existing test files
+
+**Important**: Tests should verify the spec requirements, not just that code doesn't crash.
+
+### 5. Code-Reviewer (FINAL REVIEW - batch up to 3)
+
+**Task**: Review all changes for correctness.
+
+**Check**:
+- ✅ All violations addressed per the decision phase recommendations
+- ✅ No new violations introduced
+- ✅ Tests pass and cover code changes (if any)
+- ✅ Spec updates are clear and accurate (if any)
+- ✅ No unintended side effects
+
+**Important**: Be critical. If something looks wrong, flag it and have code-writer fix it.
+
+### 6. Project-Manager (MANDATORY, ALWAYS LAST)
+
+**Task**: Document all changes in the session report.
+
+**Include**:
+- Summary of violations found
+- For each violation: decision made (FIX_CODE/UPDATE_SPEC/ADD_EXCEPTION)
+- Summary of code fixes applied
+- Summary of spec updates made
+- Test changes made (if any)
+- Any remaining issues or concerns
+
+**Important**: NEVER run project-manager in parallel. It must always be the final step.
+
+## Batching Example
+
+If you find 6 violations:
+
+- **Round 1**: 3 investigators identify violations 1-3
+- **Round 2**: 3 investigators identify violations 4-6
+- **Round 3**: 3 code-reviewers analyze violations 1-3 (DECISION PHASE - FIX_CODE/UPDATE_SPEC/ADD_EXCEPTION)
+- **Round 4**: 3 code-reviewers analyze violations 4-6 (DECISION PHASE)
+- **Round 5**: 3 code-writers apply fixes for violations 1-3 (code OR spec, per reviewer decision)
+- **Round 6**: 3 code-writers apply fixes for violations 4-6 (code OR spec, per reviewer decision)
+- **Round 7**: 3 test-writers add/update tests (ONLY for FIX_CODE decisions)
+- **Round 8**: 3 code-reviewers review all changes (FINAL REVIEW)
+- **Round 9**: 1 project-manager documents everything (LAST, NEVER PARALLEL)
+
+**Key Change**: Code-reviewer runs TWICE - once to decide the approach (step 3-4), and once to verify the changes (step 8).
+
+## Output Format
+
+Provide a compliance report at the end:
+
+```
+## Compliance Report: {{FILE_PATH}}
+
+### Spec: {{SPEC_NAME}}
+
+### Violations Found: [COUNT]
+
+**Violation 1**: [Rule ID] [Brief description]
+- Location: Line [N]
+- Code: `[snippet]`
+- Severity: [critical/high/medium/low]
+- Decision: FIX_CODE / UPDATE_SPEC / ADD_EXCEPTION
+- Reasoning: [Why this decision was made]
+- Status: RESOLVED / NEEDS_MANUAL_REVIEW
+
+**Violation 2**: ...
+
+### Code Changes Made
+
+- [File path]: [Description of code fix]
+- [Impact on codebase]
+
+### Spec Changes Made
+
+- [Spec file]: [What was updated/added]
+- [Reasoning for spec change]
+
+### Tests Added/Modified (if any code was changed)
+
+- [Test file]: [What was added/changed]
+- [Coverage impact]
+
+### Status: COMPLIANT / NEEDS_MANUAL_REVIEW
+
+**Final Assessment**: [Brief statement on compliance status]
+
+**Remaining Issues**: [Any issues that couldn't be auto-fixed]
+```
+
+## Important Notes
+
+- **This is a TRADING SYSTEM** - Mistakes can cost money. Be thorough.
+- **Spec updates are valid fixes** - If code is correct and spec is outdated, update the spec
+- **Code-reviewer decides** - Follow the code-reviewer's recommendation for each violation
+- **Test-writer follows code changes** - Always run test-writer after code is modified
+- **Fail hard** - Per CLAUDE.md, never use graceful fallbacks or silent failures
+- **NEVER run project-manager in parallel** - It must always be the final step
+- **Document everything** - Future maintainers need to understand what changed and why