Skip to content

Commit 48293ad

Browse files
committed
Add GLM click analysis notebooks and supporting files
- Update glm_clicks_to_dv_glmnet.ipynb with improved GLM implementation - Add glm_click_spacing_analysis_v001.ipynb for temporal click pattern analysis - Add glm_clicks_recovery_demo_v001.ipynb for kernel recovery demonstration - Add sklearn_vs_glmnet_comparison.md documenting differences between implementations - Add plan_mode_violation_log.md for tracking analysis issues - Add .spec-workflow/ templates for project documentation structure - Update CLAUDE.md with enhanced project preferences and instructions These changes improve the GLM analysis pipeline for linking Poisson click inputs to decision variables in the rat behavioral data.
1 parent 419b845 commit 48293ad

14 files changed

Lines changed: 6293 additions & 214 deletions

.spec-workflow/config.example.toml

Lines changed: 72 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,72 @@
1+
# Spec Workflow MCP Server Configuration File
2+
# ============================================
3+
#
4+
# This is an example configuration file for the Spec Workflow MCP Server.
5+
# Copy this file to 'config.toml' in the same directory to use it.
6+
#
7+
# Configuration Precedence:
8+
# 1. Command-line arguments (highest priority)
9+
# 2. Config file settings
10+
# 3. Built-in defaults (lowest priority)
11+
#
12+
# All settings are optional. Uncomment and modify as needed.
13+
# Please note that not all MCP clients will support loading this config file due to the nature of where they are running from.
14+
15+
# Project directory path
16+
# The root directory of your project where spec files are located.
17+
# Note: You may have to use double slashes (\\) instead of single slashes (/) on Windows or for certain clients.
18+
# Supports tilde (~) expansion for home directory.
19+
# Default: current working directory
20+
# projectDir = "."
21+
# projectDir = "~/my-project"
22+
# projectDir = "/absolute/path/to/project"
23+
24+
# Dashboard port
25+
# The port number for the web dashboard.
26+
# Must be between 1024 and 65535.
27+
# Default: ephemeral port (automatically assigned)
28+
# port = 3000
29+
30+
# Auto-start dashboard
31+
# Automatically launch the dashboard when the MCP server starts.
32+
# The dashboard will open in your default browser.
33+
# Default: false
34+
# autoStartDashboard = false
35+
36+
# Dashboard-only mode
37+
# Run only the web dashboard without the MCP server.
38+
# Useful for standalone dashboard usage.
39+
# Default: false
40+
# dashboardOnly = false
41+
42+
# Language
43+
# Set the interface language for internationalization (i18n).
44+
# Available languages depend on your installation.
45+
# Common values: "en" (English), "ja" (Japanese), etc.
46+
# Default: system language or "en"
47+
# lang = "en"
48+
49+
# Example configurations:
50+
# =====================
51+
52+
# Example 1: Development setup with auto-started dashboard
53+
# ----------------------------------------------------------
54+
# projectDir = "~/dev/my-project"
55+
# autoStartDashboard = true
56+
# port = 3456
57+
58+
# Example 2: Production MCP server without dashboard
59+
# ---------------------------------------------------
60+
# projectDir = "/var/projects/production"
61+
# autoStartDashboard = false
62+
63+
# Example 3: Dashboard-only mode for viewing specs
64+
# -------------------------------------------------
65+
# projectDir = "."
66+
# dashboardOnly = true
67+
# port = 8080
68+
69+
# Example 4: Japanese language interface
70+
# ---------------------------------------
71+
# lang = "ja"
72+
# autoStartDashboard = true
Lines changed: 96 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,96 @@
1+
# Design Document
2+
3+
## Overview
4+
5+
[High-level description of the feature and its place in the overall system]
6+
7+
## Steering Document Alignment
8+
9+
### Technical Standards (tech.md)
10+
[How the design follows documented technical patterns and standards]
11+
12+
### Project Structure (structure.md)
13+
[How the implementation will follow project organization conventions]
14+
15+
## Code Reuse Analysis
16+
[What existing code will be leveraged, extended, or integrated with this feature]
17+
18+
### Existing Components to Leverage
19+
- **[Component/Utility Name]**: [How it will be used]
20+
- **[Service/Helper Name]**: [How it will be extended]
21+
22+
### Integration Points
23+
- **[Existing System/API]**: [How the new feature will integrate]
24+
- **[Database/Storage]**: [How data will connect to existing schemas]
25+
26+
## Architecture
27+
28+
[Describe the overall architecture and design patterns used]
29+
30+
### Modular Design Principles
31+
- **Single File Responsibility**: Each file should handle one specific concern or domain
32+
- **Component Isolation**: Create small, focused components rather than large monolithic files
33+
- **Service Layer Separation**: Separate data access, business logic, and presentation layers
34+
- **Utility Modularity**: Break utilities into focused, single-purpose modules
35+
36+
```mermaid
37+
graph TD
38+
A[Component A] --> B[Component B]
39+
B --> C[Component C]
40+
```
41+
42+
## Components and Interfaces
43+
44+
### Component 1
45+
- **Purpose:** [What this component does]
46+
- **Interfaces:** [Public methods/APIs]
47+
- **Dependencies:** [What it depends on]
48+
- **Reuses:** [Existing components/utilities it builds upon]
49+
50+
### Component 2
51+
- **Purpose:** [What this component does]
52+
- **Interfaces:** [Public methods/APIs]
53+
- **Dependencies:** [What it depends on]
54+
- **Reuses:** [Existing components/utilities it builds upon]
55+
56+
## Data Models
57+
58+
### Model 1
59+
```
60+
[Define the structure of Model1 in your language]
61+
- id: [unique identifier type]
62+
- name: [string/text type]
63+
- [Additional properties as needed]
64+
```
65+
66+
### Model 2
67+
```
68+
[Define the structure of Model2 in your language]
69+
- id: [unique identifier type]
70+
- [Additional properties as needed]
71+
```
72+
73+
## Error Handling
74+
75+
### Error Scenarios
76+
1. **Scenario 1:** [Description]
77+
- **Handling:** [How to handle]
78+
- **User Impact:** [What user sees]
79+
80+
2. **Scenario 2:** [Description]
81+
- **Handling:** [How to handle]
82+
- **User Impact:** [What user sees]
83+
84+
## Testing Strategy
85+
86+
### Unit Testing
87+
- [Unit testing approach]
88+
- [Key components to test]
89+
90+
### Integration Testing
91+
- [Integration testing approach]
92+
- [Key flows to test]
93+
94+
### End-to-End Testing
95+
- [E2E testing approach]
96+
- [User scenarios to test]
Lines changed: 51 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,51 @@
1+
# Product Overview
2+
3+
## Product Purpose
4+
[Describe the core purpose of this product/project. What problem does it solve?]
5+
6+
## Target Users
7+
[Who are the primary users of this product? What are their needs and pain points?]
8+
9+
## Key Features
10+
[List the main features that deliver value to users]
11+
12+
1. **Feature 1**: [Description]
13+
2. **Feature 2**: [Description]
14+
3. **Feature 3**: [Description]
15+
16+
## Business Objectives
17+
[What are the business goals this product aims to achieve?]
18+
19+
- [Objective 1]
20+
- [Objective 2]
21+
- [Objective 3]
22+
23+
## Success Metrics
24+
[How will we measure the success of this product?]
25+
26+
- [Metric 1]: [Target]
27+
- [Metric 2]: [Target]
28+
- [Metric 3]: [Target]
29+
30+
## Product Principles
31+
[Core principles that guide product decisions]
32+
33+
1. **[Principle 1]**: [Explanation]
34+
2. **[Principle 2]**: [Explanation]
35+
3. **[Principle 3]**: [Explanation]
36+
37+
## Monitoring & Visibility (if applicable)
38+
[How do users track progress and monitor the system?]
39+
40+
- **Dashboard Type**: [e.g., Web-based, CLI, Desktop app]
41+
- **Real-time Updates**: [e.g., WebSocket, polling, push notifications]
42+
- **Key Metrics Displayed**: [What information is most important to surface]
43+
- **Sharing Capabilities**: [e.g., read-only links, exports, reports]
44+
45+
## Future Vision
46+
[Where do we see this product evolving in the future?]
47+
48+
### Potential Enhancements
49+
- **Remote Access**: [e.g., Tunnel features for sharing dashboards with stakeholders]
50+
- **Analytics**: [e.g., Historical trends, performance metrics]
51+
- **Collaboration**: [e.g., Multi-user support, commenting]
Lines changed: 50 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,50 @@
1+
# Requirements Document
2+
3+
## Introduction
4+
5+
[Provide a brief overview of the feature, its purpose, and its value to users]
6+
7+
## Alignment with Product Vision
8+
9+
[Explain how this feature supports the goals outlined in product.md]
10+
11+
## Requirements
12+
13+
### Requirement 1
14+
15+
**User Story:** As a [role], I want [feature], so that [benefit]
16+
17+
#### Acceptance Criteria
18+
19+
1. WHEN [event] THEN [system] SHALL [response]
20+
2. IF [precondition] THEN [system] SHALL [response]
21+
3. WHEN [event] AND [condition] THEN [system] SHALL [response]
22+
23+
### Requirement 2
24+
25+
**User Story:** As a [role], I want [feature], so that [benefit]
26+
27+
#### Acceptance Criteria
28+
29+
1. WHEN [event] THEN [system] SHALL [response]
30+
2. IF [precondition] THEN [system] SHALL [response]
31+
32+
## Non-Functional Requirements
33+
34+
### Code Architecture and Modularity
35+
- **Single Responsibility Principle**: Each file should have a single, well-defined purpose
36+
- **Modular Design**: Components, utilities, and services should be isolated and reusable
37+
- **Dependency Management**: Minimize interdependencies between modules
38+
- **Clear Interfaces**: Define clean contracts between components and layers
39+
40+
### Performance
41+
- [Performance requirements]
42+
43+
### Security
44+
- [Security requirements]
45+
46+
### Reliability
47+
- [Reliability requirements]
48+
49+
### Usability
50+
- [Usability requirements]

0 commit comments

Comments
 (0)