@stackmemoryai/stackmemory 1.2.1 → 1.2.2

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (39) hide show
  1. package/dist/src/cli/commands/skills.js +123 -1
  2. package/dist/src/hooks/graphiti-hooks.js +149 -0
  3. package/dist/src/hooks/session-summary.js +30 -0
  4. package/dist/src/integrations/graphiti/linear-graphiti-bridge.js +115 -0
  5. package/dist/src/integrations/greptile/client.js +101 -0
  6. package/dist/src/integrations/greptile/config.js +14 -0
  7. package/dist/src/integrations/greptile/index.js +11 -0
  8. package/dist/src/integrations/greptile/types.js +4 -0
  9. package/dist/src/integrations/linear/webhook.js +16 -0
  10. package/dist/src/integrations/mcp/handlers/greptile-handlers.js +456 -0
  11. package/dist/src/integrations/mcp/server.js +27 -0
  12. package/dist/src/skills/claude-skills.js +46 -1
  13. package/dist/src/skills/parallel-agent-skill.js +514 -0
  14. package/package.json +1 -1
  15. package/scripts/gepa/.before-optimize.md +140 -159
  16. package/scripts/gepa/config.json +7 -1
  17. package/scripts/gepa/evals/fixtures/api-endpoint.ts +31 -0
  18. package/scripts/gepa/evals/fixtures/brittle-integration.ts +38 -0
  19. package/scripts/gepa/evals/fixtures/fts5-triggers.sql +23 -0
  20. package/scripts/gepa/evals/fixtures/leaky-service.ts +70 -0
  21. package/scripts/gepa/evals/fixtures/mcp-dispatch-stub.ts +39 -0
  22. package/scripts/gepa/evals/fixtures/pr-diff.txt +24 -0
  23. package/scripts/gepa/evals/fixtures/unsafe-webhook.ts +34 -0
  24. package/scripts/gepa/evals/fixtures/unwrapped-db-op.ts +42 -0
  25. package/scripts/gepa/evals/stackmemory-tasks.jsonl +8 -0
  26. package/scripts/gepa/generations/gen-000/baseline.md +172 -159
  27. package/scripts/gepa/generations/gen-001/baseline.md +172 -159
  28. package/scripts/gepa/generations/gen-001/variant-a.md +156 -146
  29. package/scripts/gepa/generations/gen-001/variant-b.md +199 -170
  30. package/scripts/gepa/generations/gen-001/variant-c.md +127 -46
  31. package/scripts/gepa/generations/gen-001/variant-d.md +160 -107
  32. package/scripts/gepa/hooks/reflect.js +44 -5
  33. package/scripts/gepa/optimize.js +281 -39
  34. package/scripts/gepa/results/eval-1-baseline.json +187 -10
  35. package/scripts/gepa/results/eval-1-variant-a.json +188 -11
  36. package/scripts/gepa/results/eval-1-variant-b.json +188 -11
  37. package/scripts/gepa/results/eval-1-variant-c.json +168 -11
  38. package/scripts/gepa/results/eval-1-variant-d.json +169 -12
  39. package/scripts/gepa/state.json +18 -18
@@ -0,0 +1,8 @@
1
+ {"id": "sm-001", "name": "add_mcp_tool_handler", "prompt": "Add a new MCP tool handler called 'get_frame_summary' that takes a frameId (required string) and returns { frameId, name, status, eventCount }. Follow the existing switch/case dispatch pattern in server.ts. Include Zod input validation.", "input_file": "fixtures/mcp-dispatch-stub.ts", "expected": {"has_switch_case": true, "has_zod_schema": true, "validates_input": true, "returns_typed_response": true, "handles_not_found": true}, "weight": 1.5}
2
+ {"id": "sm-002", "name": "fix_fts5_trigger_bug", "prompt": "The FTS5 DELETE trigger is missing — when a frame is deleted from the frames table, the frames_fts index is not updated. Add the missing AFTER DELETE trigger following the pattern of the existing INSERT and UPDATE triggers.", "input_file": "fixtures/fts5-triggers.sql", "expected": {"has_delete_trigger": true, "uses_fts_delete_syntax": true, "references_old_row": true, "matches_column_list": true}, "weight": 1.8}
3
+ {"id": "sm-003", "name": "daemon_service_lifecycle", "prompt": "This daemon service has a timer leak — when updateConfig() restarts the service, the old interval is not cleared before creating a new one if start() is called while already running. Fix the bug and add a getState() method that returns { isRunning, intervalMs, lastRunTime, errorCount }.", "input_file": "fixtures/leaky-service.ts", "expected": {"clears_old_interval": true, "prevents_double_start": true, "has_getstate_method": true, "returns_correct_state_shape": true}, "weight": 1.5}
4
+ {"id": "sm-004", "name": "webhook_payload_validation", "prompt": "This webhook handler is vulnerable to prototype pollution and has no input length limits. Fix the validation to: 1) reject __proto__ and constructor keys, 2) limit title to 500 chars, 3) limit description to 5000 chars, 4) validate that action is one of create/update/remove.", "input_file": "fixtures/unsafe-webhook.ts", "expected": {"blocks_proto_pollution": true, "limits_title_length": true, "limits_description_length": true, "validates_action_enum": true, "returns_null_on_invalid": true}, "weight": 2.0}
5
+ {"id": "sm-005", "name": "error_handling_chain", "prompt": "Wrap this database operation in proper StackMemory error handling: use DatabaseError with appropriate ErrorCode, preserve the cause chain, set isRetryable based on error type (connection errors are retryable, constraint violations are not), and log with structured context.", "input_file": "fixtures/unwrapped-db-op.ts", "expected": {"uses_database_error": true, "preserves_cause": true, "sets_retryable_correctly": true, "has_structured_logging": true, "catches_unknown_type": true}, "weight": 1.3}
6
+ {"id": "sm-006", "name": "integration_graceful_degradation", "prompt": "This integration handler crashes the MCP server when the external API is down. Refactor it to degrade gracefully: catch connection errors, return a user-friendly MCPResponse with metadata.unavailable=true, log at debug level (not error), and don't retry on 4xx errors.", "input_file": "fixtures/brittle-integration.ts", "expected": {"catches_connection_errors": true, "returns_mcp_response": true, "sets_unavailable_metadata": true, "logs_at_debug": true, "no_retry_on_4xx": true}, "weight": 1.5}
7
+ {"id": "sm-007", "name": "sqlite_migration_safety", "prompt": "Write a safe SQLite migration that adds a 'tags' TEXT column to the frames table. The migration must: 1) check if column already exists first (idempotent), 2) wrap in a transaction, 3) update the schema_version table, 4) handle the case where schema_version table doesn't exist yet.", "expected": {"checks_column_exists": true, "uses_transaction": true, "updates_schema_version": true, "is_idempotent": true, "handles_missing_version_table": true}, "weight": 1.5}
8
+ {"id": "sm-008", "name": "review_pr_security", "prompt": "Review this PR diff and identify all security issues, performance problems, and code quality concerns. Provide actionable feedback for each issue found.", "input_file": "fixtures/pr-diff.txt", "expected": {"identifies_sql_injection": true, "identifies_plaintext_password": true, "identifies_credential_logging": true, "identifies_weak_session": true, "provides_fix_suggestions": true}, "weight": 2.0}
@@ -1,159 +1,172 @@
1
- AGENTS.md
2
-
3
- Purpose
4
- - A minimal, agent-friendly reference so code-generation agents (Codex, Claude Code, etc.) can work effectively in this repository.
5
- - Explains key docs, the /designs/ folder, agent responsibilities, and quick operational notes (how to run tests, what to update, and commit expectations).
6
-
7
- Repo doc descriptions
8
- - prompt_plan.md
9
- - The agent-driven plan that sequences work into small, testable prompts and steps.
10
- - Contains per-step prompts, expected artifacts, tests, rollback/idempotency notes, and a TODO checklist using Markdown checkboxes.
11
- - This is the canonical agent workflow driver — update it as you make progress (see Agent responsibility rules below).
12
-
13
- - spec.md
14
- - The minimal functional & technical specification that defines APIs, data models, and acceptance criteria.
15
- - Includes the concise Definition of Done that must be satisfied for each plan step before marking it complete.
16
-
17
- - idea.md
18
- - Free-form brainstorming, assumptions, notes, research links, and open questions.
19
- - Useful for context but not authoritative — always follow spec.md and prompt_plan.md for implementation decisions.
20
-
21
- - idea_one_pager.md
22
- - A short summary / one‑pager capturing Problem, Audience, Platform, Core Flow, and MVP Features (and optional Non‑Goals).
23
- - Good for quick alignment and to confirm that work stays within scope.
24
-
25
- What lives in /designs/
26
- - UI/UX artifacts and visual assets that inform implementation:
27
- - wireframes (PNG/SVG), Figma exports (.fig, .pdf), sequence diagrams, architecture diagrams (PNG/PDF/SVG), and annotated screenshots.
28
- - Naming conventions: keep filenames short, include version/date and owner, e.g., dashboard_v1_2025-11-01.png or seq_query_flow_v2.pdf.
29
- - Large source Figma files may live externally; include an export + a small README describing where the canonical design is stored and any viewing permissions required.
30
-
31
- How agents should interact (summary)
32
- - Treat prompt_plan.md as the authoritative workflow: follow the listed prompts in order and mark checklist items as you finish them.
33
- - Always follow TDD: write tests first, make the minimal change to pass tests, then refactor while keeping tests green.
34
- - After any code/test change, update the matching TODO checkbox in prompt_plan.md using the same Markdown checkbox format ('- [x]') and commit the change alongside code and tests.
35
- - Make the smallest change that passes tests and improves code. Do not introduce new public APIs without updating spec.md and tests.
36
- - Don't duplicate templates/files to work around errors — fix the original.
37
- - Suggest a clear manual test path for every change (even when tests cover it).
38
- - If you cannot open a file or content is missing, say so explicitly and stop. Do not guess.
39
-
40
- Quick operational commands (expect these to exist; if not, ask)
41
- - npm run dev — start local dev server
42
- - npm test run unit + integration test suite
43
- - npm run lint — run linting
44
- - npm run build — build TypeScript
45
- - npm run migrate:up / migrate:down — database migrations
46
-
47
- Commit & PR expectations
48
- - Each prompt/plan step should result in a single, focused commit/PR with:
49
- - Code + tests + prompt_plan.md checklist update.
50
- - A short, copy-pasteable commit summary in the prompt_plan.md step completion entry.
51
- - Clear CHANGELOG or Release notes entry if user-facing behavior changed (or explicitly state "No user-facing changes").
52
- - Use atomic commits. Include test run results in PR description.
53
-
54
- Include this governance / workflow block verbatim (do not modify)
55
- ## Repository docs
56
- - 'ONE_PAGER.md' - Captures Problem, Audience, Platform, Core Flow, MVP Features; Non-Goals optional.
57
- - 'DEV_SPEC.md' - Minimal functional and technical specification consistent with prior docs, including a concise **Definition of Done**.
58
- - 'PROMPT_PLAN.md' - Agent-Ready Planner with per-step prompts, expected artifacts, tests, rollback notes, idempotency notes, and a TODO checklist using Markdown checkboxes. This file drives the agent workflow.
59
- - 'docs/STYLE.md' - Unified design system reference. Typography, layout, color tokens, component patterns. Inspired by Hatchet (structural layout, inset panels) and Outliner (clean hierarchy, whitespace). **All dashboard UI changes must follow this guide.**
60
- - 'AGENTS.md' - This file.
61
-
62
- ### Agent responsibility
63
- - After completing any coding, refactor, or test step, **immediately update the corresponding TODO checklist item in 'prompt_plan.md'**.
64
- - Use the same Markdown checkbox format ('- [x]') to mark completion.
65
- - When creating new tasks or subtasks, add them directly under the appropriate section anchor in 'prompt_plan.md'.
66
- - Always commit changes to 'prompt_plan.md' alongside the code and tests that fulfill them.
67
- - Do not consider work "done" until the matching checklist item is checked and all related tests are green.
68
- - When a stage (plan step) is complete with green tests, update the README "Release notes" section with any user-facing impact (or explicitly state "No user-facing changes" if applicable).
69
- - Even when automated coverage exists, always suggest a feasible manual test path so the human can exercise the feature end-to-end.
70
- - After a plan step is finished, document its completion state with a short checklist. Include: step name & number, test results, 'prompt_plan.md' status, manual checks performed (mark as complete only after the human confirms they ran to their satisfaction), release notes status, and an inline commit summary string the human can copy & paste.
71
-
72
- #### Guardrails for agents
73
- - Make the smallest change that passes tests and improves the code.
74
- - Do not introduce new public APIs without updating 'spec.md' and relevant tests.
75
- - Do not duplicate templates or files to work around issues. Fix the original.
76
- - If a file cannot be opened or content is missing, say so explicitly and stop. Do not guess.
77
- - Respect privacy and logging policy: do not log secrets, prompts, completions, or PII.
78
-
79
- #### Deferred-work notation
80
- - When a task is intentionally paused, keep its checkbox unchecked and prepend '(Deferred)' to the TODO label in 'prompt_plan.md', followed by a short reason.
81
- - Apply the same '(Deferred)' tag to every downstream checklist item that depends on the paused work.
82
- - Remove the tag only after the work resumes; this keeps the outstanding scope visible without implying completion.
83
-
84
-
85
-
86
- #### When the prompt plan is fully satisfied
87
- - Once every Definition of Done task in 'prompt_plan.md' is either checked off or explicitly marked '(Deferred)', the plan is considered **complete**.
88
- - After that point, you no longer need to update prompt-plan TODOs or reference 'prompt_plan.md', 'spec.md', 'idea_one_pager.md', or other upstream docs to justify changes.
89
- - All other guardrails, testing requirements, and agent responsibilities in this file continue to apply unchanged.
90
-
91
-
92
- ---
93
-
94
- ## Testing policy (non-negotiable)
95
- - Tests **MUST** cover the functionality being implemented.
96
- - **NEVER** ignore the output of the system or the tests - logs and messages often contain **CRITICAL** information.
97
- - **TEST OUTPUT MUST BE PRISTINE TO PASS.**
98
- - If logs are **supposed** to contain errors, capture and test it.
99
- - **NO EXCEPTIONS POLICY:** Under no circumstances should you mark any test type as "not applicable". Every project, regardless of size or complexity, **MUST** have unit tests, integration tests, **AND** end-to-end tests. If you believe a test type doesn't apply, you need the human to say exactly **"I AUTHORIZE YOU TO SKIP WRITING TESTS THIS TIME"**.
100
-
101
- ### TDD (how we work)
102
- - Write tests **before** implementation.
103
- - Only write enough code to make the failing test pass.
104
- - Refactor continuously while keeping tests green.
105
-
106
- **TDD cycle**
107
- 1. Write a failing test that defines a desired function or improvement.
108
- 2. Run the test to confirm it fails as expected.
109
- 3. Write minimal code to make the test pass.
110
- 4. Run the test to confirm success.
111
- 5. Refactor while keeping tests green.
112
- 6. Repeat for each new feature or bugfix.
113
-
114
- ---
115
-
116
- ## Important checks
117
- - **NEVER** disable functionality to hide a failure. Fix root cause.
118
- - **NEVER** create duplicate templates or files. Fix the original.
119
- - **NEVER** claim something is "working" when any functionality is disabled or broken.
120
- - If you can't open a file or access something requested, say so. Do not assume contents.
121
- - **ALWAYS** identify and fix the root cause of template or compilation errors.
122
- - If git is initialized, ensure a '.gitignore' exists and contains at least:
123
-
124
- .env
125
- .env.local
126
- .env.*
127
-
128
- Ask the human whether additional patterns should be added, and suggest any that you think are important given the project.
129
-
130
- ## When to ask for human input
131
- Ask the human if any of the following is true:
132
- - A test type appears "not applicable". Use the exact phrase request: **"I AUTHORIZE YOU TO SKIP WRITING TESTS THIS TIME"**.
133
- - Required anchors conflict or are missing from upstream docs.
134
- - You need new environment variables or secrets.
135
- - An external dependency or major architectural change is required.
136
- - Design files are missing, unsupported or oversized
137
-
138
- (End of verbatim block)
139
-
140
- Minimal examples for checklist updates (copy/pasteable)
141
- - After completing a prompt step, add an entry under that step in prompt_plan.md similar to:
142
- - [x] Step 5 Implement POST /api/v1/query — tests green — manual checks: cURL example tested — README Release Notes updated — commit: "query: add /api/v1/query route, adapter integration, tests"
143
- - If pausing work:
144
- - - [ ] (Deferred) Step 7.3 — Implement real Pinecone adapter — blocked on PINECONE_API_KEY (reason: waiting for dev key from infra)
145
-
146
- If anything is missing
147
- - If you cannot open prompt_plan.md, spec.md, idea.md, idea_one_pager.md, or any design file, stop and report exactly which file and why (permission/absent/parse error).
148
- - Ask for required secrets or permissions rather than guessing. Use the "When to ask for human input" rules above.
149
-
150
- Contact & escalation
151
- - When blocked on infra/secrets/design files, create a short note in prompt_plan.md under the current step and ping the human with:
152
- - What I need: (e.g., PINECONE_API_KEY, AWS dev creds)
153
- - Why I need it: (which step/blocker)
154
- - Recommended minimal next action & fallback
155
-
156
- Notes
157
- - Keep AGENTS.md and the rest of the repo docs in sync. Update this file if workflow expectations change.
158
-
159
- End.
1
+ # StackMemory - Project Configuration
2
+
3
+ ## Project Structure
4
+
5
+ ```
6
+ src/
7
+ cli/ # CLI commands and entry point
8
+ core/ # Core business logic
9
+ context/ # Frame and context management
10
+ database/ # Database adapters (SQLite, ParadeDB)
11
+ digest/ # Digest generation
12
+ query/ # Query parsing and routing
13
+ integrations/ # External integrations (Linear, MCP)
14
+ services/ # Business services
15
+ skills/ # Claude Code skills
16
+ utils/ # Shared utilities
17
+ scripts/ # Build and utility scripts
18
+ config/ # Configuration files
19
+ docs/ # Documentation
20
+ ```
21
+
22
+ ## Key Files
23
+
24
+ - Entry: src/cli/index.ts
25
+ - MCP Server: src/integrations/mcp/server.ts
26
+ - Frame Manager: src/core/context/frame-manager.ts
27
+ - Database: src/core/database/sqlite-adapter.ts
28
+
29
+ ## Detailed Guides
30
+
31
+ Quick reference (agent_docs/):
32
+ - linear_integration.md - Linear sync
33
+ - mcp_server.md - MCP tools
34
+ - database_storage.md - Storage
35
+ - claude_hooks.md - Hooks
36
+
37
+ Full documentation (docs/):
38
+ - principles.md - Agent programming paradigm
39
+ - architecture.md - Extension model and browser sandbox
40
+ - SPEC.md - Technical specification
41
+ - API_REFERENCE.md - API docs
42
+ - DEVELOPMENT.md - Dev guide
43
+ - SETUP.md - Installation
44
+
45
+ ## Commands
46
+
47
+ ```bash
48
+ npm run build # Compile TypeScript (esbuild)
49
+ npm run lint # ESLint check
50
+ npm run lint:fix # Auto-fix lint issues
51
+ npm test # Run Vitest (watch)
52
+ npm run test:run # Run tests once
53
+ npm run linear:sync # Sync with Linear
54
+
55
+ # StackMemory CLI
56
+ stackmemory capture # Save session state for handoff
57
+ stackmemory restore # Restore from captured state
58
+ ```
59
+
60
+ ## Working Directory
61
+
62
+ - PRIMARY: /Users/jwu/Dev/stackmemory
63
+ - ALLOWED: All subdirectories
64
+ - TEMP: /tmp for temporary operations
65
+
66
+ ## Validation (MUST DO)
67
+
68
+ After code changes:
69
+ 1. `npm run lint` - fix any errors AND warnings
70
+ 2. `npm run test:run` - verify no regressions
71
+ 3. `npm run build` - ensure compilation
72
+ 4. Run code to verify it works
73
+
74
+ Test coverage:
75
+ - New features require tests in `src/**/__tests__/`
76
+ - Maintain or improve coverage (no untested code paths)
77
+ - Critical paths: context management, handoff, Linear sync
78
+
79
+ Never: Assume success | Skip testing | Use mock data as fallback
80
+
81
+ ## Git Rules (CRITICAL)
82
+
83
+ - NEVER use `--no-verify` on git push or commit
84
+ - ALWAYS fix lint/test errors before pushing
85
+ - If pre-push hooks fail, fix the underlying issue
86
+ - Run `npm run lint && npm run test:run` before pushing
87
+ - Commit message format: `type(scope): message`
88
+ - Branch naming: `feature/STA-XXX-description` | `fix/STA-XXX-description` | `chore/description`
89
+
90
+ ## Task Management
91
+
92
+ - Use TodoWrite for 3+ steps or multiple requests
93
+ - Keep one task in_progress at a time
94
+ - Update task status immediately on completion
95
+
96
+ ## Security
97
+
98
+ NEVER hardcode secrets - use process.env with dotenv/config
99
+
100
+ ```javascript
101
+ import 'dotenv/config';
102
+ const API_KEY = process.env.LINEAR_API_KEY;
103
+ if (!API_KEY) {
104
+ console.error('LINEAR_API_KEY not set');
105
+ process.exit(1);
106
+ }
107
+ ```
108
+
109
+ Environment sources (check in order):
110
+ 1. .env file
111
+ 2. .env.local
112
+ 3. ~/.zshrc
113
+ 4. Process environment
114
+
115
+ Secret patterns to block: lin_api_* | lin_oauth_* | sk-* | npm_*
116
+
117
+ ## Deploy
118
+
119
+ ```bash
120
+ # npm publish (uses NPM_TOKEN from .env, no OTP needed)
121
+ git stash -- scripts/gepa/ # stash GEPA state (dirties working tree)
122
+ NPM_TOKEN=$(grep '^NPM_TOKEN=' .env | cut -d= -f2) \
123
+ npm publish --registry https://registry.npmjs.org/ \
124
+ --//registry.npmjs.org/:_authToken="$NPM_TOKEN"
125
+ git stash pop # restore GEPA state
126
+
127
+ # Railway
128
+ railway up
129
+
130
+ # Pre-publish checks require clean git status — stash GEPA files first
131
+ ```
132
+
133
+ ## Task Delegation Model
134
+
135
+ Route effort by task complexity not all code changes deserve equal scrutiny:
136
+
137
+ **AUTOMATE** — Execute immediately, lint+test is sufficient:
138
+ - CRUD operations, boilerplate, formatting, simple transforms
139
+ - Adding a tool handler following existing switch/case pattern
140
+ - Config additions (new env var, feature flag)
141
+
142
+ **STANDARD**Normal workflow, lint+test+build:
143
+ - Feature implementation, bug fixes, refactoring
144
+ - New test coverage, documentation updates
145
+ - Integration wiring (adding handler to server.ts dispatch)
146
+
147
+ **CAREFUL** Review approach before implementation:
148
+ - API/schema changes, database migrations, auth flows
149
+ - New integration patterns (MCP tools, webhook handlers)
150
+ - Changes to frame-manager, sqlite-adapter, or daemon lifecycle
151
+ - Anything touching error handling chains
152
+
153
+ **ARCHITECT** Plan mode required, explore existing patterns first:
154
+ - New service boundaries, system integrations
155
+ - Performance-critical paths (FTS5 queries, search scoring)
156
+ - Breaking changes to MCP protocol or CLI interface
157
+
158
+ **HUMAN** — Explicit user approval before any changes:
159
+ - Security-critical decisions, secret handling
160
+ - Irreversible operations (data migrations, schema drops)
161
+ - Publishing (npm publish, Railway deploy)
162
+
163
+ Quality gates scale with tier — don't over-engineer AUTOMATE tasks, don't under-review CAREFUL ones.
164
+
165
+ ## Workflow
166
+
167
+ - Check .env for API keys before asking
168
+ - Run npm run linear:sync after task completion
169
+ - Use browser MCP for visual testing
170
+ - Review recent commits and stackmemory.json on session start
171
+ - Use subagents for multi-step tasks
172
+ - Ask 1-3 clarifying questions for complex commands (one at a time)