feat(kb): chunk_index in /kb/search hits + section-window in /source/{id}/chunks
Two minimal additions for the upcoming v0.1.11 client work:
- /kb/search hits now include chunk_index, so the client can call
/source/{id}/chunks?around=N&ctx=K to fetch the matched chunk plus K
chunks before/after as context. Required by the new search-preview
layout for text sources, which until now duplicated the matched chunk
in both panes.
- /source/{id}/chunks accepts around (chunk_index) + ctx (window radius
clamped to 0..10). When around is given, returns only the windowed
range; otherwise unchanged (returns all chunks of the source).
Refs Task Master #1
This commit is contained in:
+24
@@ -7,3 +7,27 @@ venv/
|
||||
.env
|
||||
*.log
|
||||
.pytest_cache/
|
||||
|
||||
# Logs
|
||||
logs
|
||||
npm-debug.log*
|
||||
yarn-debug.log*
|
||||
yarn-error.log*
|
||||
dev-debug.log
|
||||
# Dependency directories
|
||||
node_modules/
|
||||
# Environment variables
|
||||
# Editor directories and files
|
||||
.idea
|
||||
.vscode
|
||||
*.suo
|
||||
*.ntvs*
|
||||
*.njsproj
|
||||
*.sln
|
||||
*.sw?
|
||||
# OS specific
|
||||
.DS_Store
|
||||
|
||||
# Task files
|
||||
# tasks.json
|
||||
# tasks/
|
||||
|
||||
@@ -0,0 +1,44 @@
|
||||
{
|
||||
"models": {
|
||||
"main": {
|
||||
"provider": "anthropic",
|
||||
"modelId": "claude-sonnet-4-20250514",
|
||||
"maxTokens": 64000,
|
||||
"temperature": 0.2
|
||||
},
|
||||
"research": {
|
||||
"provider": "perplexity",
|
||||
"modelId": "sonar",
|
||||
"maxTokens": 8700,
|
||||
"temperature": 0.1
|
||||
},
|
||||
"fallback": {
|
||||
"provider": "anthropic",
|
||||
"modelId": "claude-3-7-sonnet-20250219",
|
||||
"maxTokens": 120000,
|
||||
"temperature": 0.2
|
||||
}
|
||||
},
|
||||
"global": {
|
||||
"logLevel": "info",
|
||||
"debug": false,
|
||||
"defaultNumTasks": 10,
|
||||
"defaultSubtasks": 5,
|
||||
"defaultPriority": "medium",
|
||||
"projectName": "Task Master",
|
||||
"ollamaBaseURL": "http://localhost:11434/api",
|
||||
"bedrockBaseURL": "https://bedrock.us-east-1.amazonaws.com",
|
||||
"responseLanguage": "English",
|
||||
"enableCodebaseAnalysis": true,
|
||||
"enableProxy": false,
|
||||
"anonymousTelemetry": true,
|
||||
"userId": "1234567890"
|
||||
},
|
||||
"claudeCode": {},
|
||||
"codexCli": {},
|
||||
"grokCli": {
|
||||
"timeout": 120000,
|
||||
"workingDirectory": null,
|
||||
"defaultModel": "grok-4-latest"
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,6 @@
|
||||
{
|
||||
"currentTag": "master",
|
||||
"lastSwitched": "2026-04-19T06:09:58.720Z",
|
||||
"branchTagMapping": {},
|
||||
"migrationNoticeShown": true
|
||||
}
|
||||
@@ -0,0 +1,47 @@
|
||||
<context>
|
||||
# Overview
|
||||
[Provide a high-level overview of your product here. Explain what problem it solves, who it's for, and why it's valuable.]
|
||||
|
||||
# Core Features
|
||||
[List and describe the main features of your product. For each feature, include:
|
||||
- What it does
|
||||
- Why it's important
|
||||
- How it works at a high level]
|
||||
|
||||
# User Experience
|
||||
[Describe the user journey and experience. Include:
|
||||
- User personas
|
||||
- Key user flows
|
||||
- UI/UX considerations]
|
||||
</context>
|
||||
<PRD>
|
||||
# Technical Architecture
|
||||
[Outline the technical implementation details:
|
||||
- System components
|
||||
- Data models
|
||||
- APIs and integrations
|
||||
- Infrastructure requirements]
|
||||
|
||||
# Development Roadmap
|
||||
[Break down the development process into phases:
|
||||
- MVP requirements
|
||||
- Future enhancements
|
||||
- Do not think about timelines whatsoever -- all that matters is scope and detailing exactly what needs to be build in each phase so it can later be cut up into tasks]
|
||||
|
||||
# Logical Dependency Chain
|
||||
[Define the logical order of development:
|
||||
- Which features need to be built first (foundation)
|
||||
- Getting as quickly as possible to something usable/visible front end that works
|
||||
- Properly pacing and scoping each feature so it is atomic but can also be built upon and improved as development approaches]
|
||||
|
||||
# Risks and Mitigations
|
||||
[Identify potential risks and how they'll be addressed:
|
||||
- Technical challenges
|
||||
- Figuring out the MVP that we can build upon
|
||||
- Resource constraints]
|
||||
|
||||
# Appendix
|
||||
[Include any additional information:
|
||||
- Research findings
|
||||
- Technical specifications]
|
||||
</PRD>
|
||||
@@ -0,0 +1,511 @@
|
||||
<rpg-method>
|
||||
# Repository Planning Graph (RPG) Method - PRD Template
|
||||
|
||||
This template teaches you (AI or human) how to create structured, dependency-aware PRDs using the RPG methodology from Microsoft Research. The key insight: separate WHAT (functional) from HOW (structural), then connect them with explicit dependencies.
|
||||
|
||||
## Core Principles
|
||||
|
||||
1. **Dual-Semantics**: Think functional (capabilities) AND structural (code organization) separately, then map them
|
||||
2. **Explicit Dependencies**: Never assume - always state what depends on what
|
||||
3. **Topological Order**: Build foundation first, then layers on top
|
||||
4. **Progressive Refinement**: Start broad, refine iteratively
|
||||
|
||||
## How to Use This Template
|
||||
|
||||
- Follow the instructions in each `<instruction>` block
|
||||
- Look at `<example>` blocks to see good vs bad patterns
|
||||
- Fill in the content sections with your project details
|
||||
- The AI reading this will learn the RPG method by following along
|
||||
- Task Master will parse the resulting PRD into dependency-aware tasks
|
||||
|
||||
## Recommended Tools for Creating PRDs
|
||||
|
||||
When using this template to **create** a PRD (not parse it), use **code-context-aware AI assistants** for best results:
|
||||
|
||||
**Why?** The AI needs to understand your existing codebase to make good architectural decisions about modules, dependencies, and integration points.
|
||||
|
||||
**Recommended tools:**
|
||||
- **Claude Code** (claude-code CLI) - Best for structured reasoning and large contexts
|
||||
- **Cursor/Windsurf** - IDE integration with full codebase context
|
||||
- **Gemini CLI** (gemini-cli) - Massive context window for large codebases
|
||||
- **Codex/Grok CLI** - Strong code generation with context awareness
|
||||
|
||||
**Note:** Once your PRD is created, `task-master parse-prd` works with any configured AI model - it just needs to read the PRD text itself, not your codebase.
|
||||
</rpg-method>
|
||||
|
||||
---
|
||||
|
||||
<overview>
|
||||
<instruction>
|
||||
Start with the problem, not the solution. Be specific about:
|
||||
- What pain point exists?
|
||||
- Who experiences it?
|
||||
- Why existing solutions don't work?
|
||||
- What success looks like (measurable outcomes)?
|
||||
|
||||
Keep this section focused - don't jump into implementation details yet.
|
||||
</instruction>
|
||||
|
||||
## Problem Statement
|
||||
[Describe the core problem. Be concrete about user pain points.]
|
||||
|
||||
## Target Users
|
||||
[Define personas, their workflows, and what they're trying to achieve.]
|
||||
|
||||
## Success Metrics
|
||||
[Quantifiable outcomes. Examples: "80% task completion via autopilot", "< 5% manual intervention rate"]
|
||||
|
||||
</overview>
|
||||
|
||||
---
|
||||
|
||||
<functional-decomposition>
|
||||
<instruction>
|
||||
Now think about CAPABILITIES (what the system DOES), not code structure yet.
|
||||
|
||||
Step 1: Identify high-level capability domains
|
||||
- Think: "What major things does this system do?"
|
||||
- Examples: Data Management, Core Processing, Presentation Layer
|
||||
|
||||
Step 2: For each capability, enumerate specific features
|
||||
- Use explore-exploit strategy:
|
||||
* Exploit: What features are REQUIRED for core value?
|
||||
* Explore: What features make this domain COMPLETE?
|
||||
|
||||
Step 3: For each feature, define:
|
||||
- Description: What it does in one sentence
|
||||
- Inputs: What data/context it needs
|
||||
- Outputs: What it produces/returns
|
||||
- Behavior: Key logic or transformations
|
||||
|
||||
<example type="good">
|
||||
Capability: Data Validation
|
||||
Feature: Schema validation
|
||||
- Description: Validate JSON payloads against defined schemas
|
||||
- Inputs: JSON object, schema definition
|
||||
- Outputs: Validation result (pass/fail) + error details
|
||||
- Behavior: Iterate fields, check types, enforce constraints
|
||||
|
||||
Feature: Business rule validation
|
||||
- Description: Apply domain-specific validation rules
|
||||
- Inputs: Validated data object, rule set
|
||||
- Outputs: Boolean + list of violated rules
|
||||
- Behavior: Execute rules sequentially, short-circuit on failure
|
||||
</example>
|
||||
|
||||
<example type="bad">
|
||||
Capability: validation.js
|
||||
(Problem: This is a FILE, not a CAPABILITY. Mixing structure into functional thinking.)
|
||||
|
||||
Capability: Validation
|
||||
Feature: Make sure data is good
|
||||
(Problem: Too vague. No inputs/outputs. Not actionable.)
|
||||
</example>
|
||||
</instruction>
|
||||
|
||||
## Capability Tree
|
||||
|
||||
### Capability: [Name]
|
||||
[Brief description of what this capability domain covers]
|
||||
|
||||
#### Feature: [Name]
|
||||
- **Description**: [One sentence]
|
||||
- **Inputs**: [What it needs]
|
||||
- **Outputs**: [What it produces]
|
||||
- **Behavior**: [Key logic]
|
||||
|
||||
#### Feature: [Name]
|
||||
- **Description**:
|
||||
- **Inputs**:
|
||||
- **Outputs**:
|
||||
- **Behavior**:
|
||||
|
||||
### Capability: [Name]
|
||||
...
|
||||
|
||||
</functional-decomposition>
|
||||
|
||||
---
|
||||
|
||||
<structural-decomposition>
|
||||
<instruction>
|
||||
NOW think about code organization. Map capabilities to actual file/folder structure.
|
||||
|
||||
Rules:
|
||||
1. Each capability maps to a module (folder or file)
|
||||
2. Features within a capability map to functions/classes
|
||||
3. Use clear module boundaries - each module has ONE responsibility
|
||||
4. Define what each module exports (public interface)
|
||||
|
||||
The goal: Create a clear mapping between "what it does" (functional) and "where it lives" (structural).
|
||||
|
||||
<example type="good">
|
||||
Capability: Data Validation
|
||||
→ Maps to: src/validation/
|
||||
├── schema-validator.js (Schema validation feature)
|
||||
├── rule-validator.js (Business rule validation feature)
|
||||
└── index.js (Public exports)
|
||||
|
||||
Exports:
|
||||
- validateSchema(data, schema)
|
||||
- validateRules(data, rules)
|
||||
</example>
|
||||
|
||||
<example type="bad">
|
||||
Capability: Data Validation
|
||||
→ Maps to: src/utils.js
|
||||
(Problem: "utils" is not a clear module boundary. Where do I find validation logic?)
|
||||
|
||||
Capability: Data Validation
|
||||
→ Maps to: src/validation/everything.js
|
||||
(Problem: One giant file. Features should map to separate files for maintainability.)
|
||||
</example>
|
||||
</instruction>
|
||||
|
||||
## Repository Structure
|
||||
|
||||
```
|
||||
project-root/
|
||||
├── src/
|
||||
│ ├── [module-name]/ # Maps to: [Capability Name]
|
||||
│ │ ├── [file].js # Maps to: [Feature Name]
|
||||
│ │ └── index.js # Public exports
|
||||
│ └── [module-name]/
|
||||
├── tests/
|
||||
└── docs/
|
||||
```
|
||||
|
||||
## Module Definitions
|
||||
|
||||
### Module: [Name]
|
||||
- **Maps to capability**: [Capability from functional decomposition]
|
||||
- **Responsibility**: [Single clear purpose]
|
||||
- **File structure**:
|
||||
```
|
||||
module-name/
|
||||
├── feature1.js
|
||||
├── feature2.js
|
||||
└── index.js
|
||||
```
|
||||
- **Exports**:
|
||||
- `functionName()` - [what it does]
|
||||
- `ClassName` - [what it does]
|
||||
|
||||
</structural-decomposition>
|
||||
|
||||
---
|
||||
|
||||
<dependency-graph>
|
||||
<instruction>
|
||||
This is THE CRITICAL SECTION for Task Master parsing.
|
||||
|
||||
Define explicit dependencies between modules. This creates the topological order for task execution.
|
||||
|
||||
Rules:
|
||||
1. List modules in dependency order (foundation first)
|
||||
2. For each module, state what it depends on
|
||||
3. Foundation modules should have NO dependencies
|
||||
4. Every non-foundation module should depend on at least one other module
|
||||
5. Think: "What must EXIST before I can build this module?"
|
||||
|
||||
<example type="good">
|
||||
Foundation Layer (no dependencies):
|
||||
- error-handling: No dependencies
|
||||
- config-manager: No dependencies
|
||||
- base-types: No dependencies
|
||||
|
||||
Data Layer:
|
||||
- schema-validator: Depends on [base-types, error-handling]
|
||||
- data-ingestion: Depends on [schema-validator, config-manager]
|
||||
|
||||
Core Layer:
|
||||
- algorithm-engine: Depends on [base-types, error-handling]
|
||||
- pipeline-orchestrator: Depends on [algorithm-engine, data-ingestion]
|
||||
</example>
|
||||
|
||||
<example type="bad">
|
||||
- validation: Depends on API
|
||||
- API: Depends on validation
|
||||
(Problem: Circular dependency. This will cause build/runtime issues.)
|
||||
|
||||
- user-auth: Depends on everything
|
||||
(Problem: Too many dependencies. Should be more focused.)
|
||||
</example>
|
||||
</instruction>
|
||||
|
||||
## Dependency Chain
|
||||
|
||||
### Foundation Layer (Phase 0)
|
||||
No dependencies - these are built first.
|
||||
|
||||
- **[Module Name]**: [What it provides]
|
||||
- **[Module Name]**: [What it provides]
|
||||
|
||||
### [Layer Name] (Phase 1)
|
||||
- **[Module Name]**: Depends on [[module-from-phase-0], [module-from-phase-0]]
|
||||
- **[Module Name]**: Depends on [[module-from-phase-0]]
|
||||
|
||||
### [Layer Name] (Phase 2)
|
||||
- **[Module Name]**: Depends on [[module-from-phase-1], [module-from-foundation]]
|
||||
|
||||
[Continue building up layers...]
|
||||
|
||||
</dependency-graph>
|
||||
|
||||
---
|
||||
|
||||
<implementation-roadmap>
|
||||
<instruction>
|
||||
Turn the dependency graph into concrete development phases.
|
||||
|
||||
Each phase should:
|
||||
1. Have clear entry criteria (what must exist before starting)
|
||||
2. Contain tasks that can be parallelized (no inter-dependencies within phase)
|
||||
3. Have clear exit criteria (how do we know phase is complete?)
|
||||
4. Build toward something USABLE (not just infrastructure)
|
||||
|
||||
Phase ordering follows topological sort of dependency graph.
|
||||
|
||||
<example type="good">
|
||||
Phase 0: Foundation
|
||||
Entry: Clean repository
|
||||
Tasks:
|
||||
- Implement error handling utilities
|
||||
- Create base type definitions
|
||||
- Setup configuration system
|
||||
Exit: Other modules can import foundation without errors
|
||||
|
||||
Phase 1: Data Layer
|
||||
Entry: Phase 0 complete
|
||||
Tasks:
|
||||
- Implement schema validator (uses: base types, error handling)
|
||||
- Build data ingestion pipeline (uses: validator, config)
|
||||
Exit: End-to-end data flow from input to validated output
|
||||
</example>
|
||||
|
||||
<example type="bad">
|
||||
Phase 1: Build Everything
|
||||
Tasks:
|
||||
- API
|
||||
- Database
|
||||
- UI
|
||||
- Tests
|
||||
(Problem: No clear focus. Too broad. Dependencies not considered.)
|
||||
</example>
|
||||
</instruction>
|
||||
|
||||
## Development Phases
|
||||
|
||||
### Phase 0: [Foundation Name]
|
||||
**Goal**: [What foundational capability this establishes]
|
||||
|
||||
**Entry Criteria**: [What must be true before starting]
|
||||
|
||||
**Tasks**:
|
||||
- [ ] [Task name] (depends on: [none or list])
|
||||
- Acceptance criteria: [How we know it's done]
|
||||
- Test strategy: [What tests prove it works]
|
||||
|
||||
- [ ] [Task name] (depends on: [none or list])
|
||||
|
||||
**Exit Criteria**: [Observable outcome that proves phase complete]
|
||||
|
||||
**Delivers**: [What can users/developers do after this phase?]
|
||||
|
||||
---
|
||||
|
||||
### Phase 1: [Layer Name]
|
||||
**Goal**:
|
||||
|
||||
**Entry Criteria**: Phase 0 complete
|
||||
|
||||
**Tasks**:
|
||||
- [ ] [Task name] (depends on: [[tasks-from-phase-0]])
|
||||
- [ ] [Task name] (depends on: [[tasks-from-phase-0]])
|
||||
|
||||
**Exit Criteria**:
|
||||
|
||||
**Delivers**:
|
||||
|
||||
---
|
||||
|
||||
[Continue with more phases...]
|
||||
|
||||
</implementation-roadmap>
|
||||
|
||||
---
|
||||
|
||||
<test-strategy>
|
||||
<instruction>
|
||||
Define how testing will be integrated throughout development (TDD approach).
|
||||
|
||||
Specify:
|
||||
1. Test pyramid ratios (unit vs integration vs e2e)
|
||||
2. Coverage requirements
|
||||
3. Critical test scenarios
|
||||
4. Test generation guidelines for Surgical Test Generator
|
||||
|
||||
This section guides the AI when generating tests during the RED phase of TDD.
|
||||
|
||||
<example type="good">
|
||||
Critical Test Scenarios for Data Validation module:
|
||||
- Happy path: Valid data passes all checks
|
||||
- Edge cases: Empty strings, null values, boundary numbers
|
||||
- Error cases: Invalid types, missing required fields
|
||||
- Integration: Validator works with ingestion pipeline
|
||||
</example>
|
||||
</instruction>
|
||||
|
||||
## Test Pyramid
|
||||
|
||||
```
|
||||
/\
|
||||
/E2E\ ← [X]% (End-to-end, slow, comprehensive)
|
||||
/------\
|
||||
/Integration\ ← [Y]% (Module interactions)
|
||||
/------------\
|
||||
/ Unit Tests \ ← [Z]% (Fast, isolated, deterministic)
|
||||
/----------------\
|
||||
```
|
||||
|
||||
## Coverage Requirements
|
||||
- Line coverage: [X]% minimum
|
||||
- Branch coverage: [X]% minimum
|
||||
- Function coverage: [X]% minimum
|
||||
- Statement coverage: [X]% minimum
|
||||
|
||||
## Critical Test Scenarios
|
||||
|
||||
### [Module/Feature Name]
|
||||
**Happy path**:
|
||||
- [Scenario description]
|
||||
- Expected: [What should happen]
|
||||
|
||||
**Edge cases**:
|
||||
- [Scenario description]
|
||||
- Expected: [What should happen]
|
||||
|
||||
**Error cases**:
|
||||
- [Scenario description]
|
||||
- Expected: [How system handles failure]
|
||||
|
||||
**Integration points**:
|
||||
- [What interactions to test]
|
||||
- Expected: [End-to-end behavior]
|
||||
|
||||
## Test Generation Guidelines
|
||||
[Specific instructions for Surgical Test Generator about what to focus on, what patterns to follow, project-specific test conventions]
|
||||
|
||||
</test-strategy>
|
||||
|
||||
---
|
||||
|
||||
<architecture>
|
||||
<instruction>
|
||||
Describe technical architecture, data models, and key design decisions.
|
||||
|
||||
Keep this section AFTER functional/structural decomposition - implementation details come after understanding structure.
|
||||
</instruction>
|
||||
|
||||
## System Components
|
||||
[Major architectural pieces and their responsibilities]
|
||||
|
||||
## Data Models
|
||||
[Core data structures, schemas, database design]
|
||||
|
||||
## Technology Stack
|
||||
[Languages, frameworks, key libraries]
|
||||
|
||||
**Decision: [Technology/Pattern]**
|
||||
- **Rationale**: [Why chosen]
|
||||
- **Trade-offs**: [What we're giving up]
|
||||
- **Alternatives considered**: [What else we looked at]
|
||||
|
||||
</architecture>
|
||||
|
||||
---
|
||||
|
||||
<risks>
|
||||
<instruction>
|
||||
Identify risks that could derail development and how to mitigate them.
|
||||
|
||||
Categories:
|
||||
- Technical risks (complexity, unknowns)
|
||||
- Dependency risks (blocking issues)
|
||||
- Scope risks (creep, underestimation)
|
||||
</instruction>
|
||||
|
||||
## Technical Risks
|
||||
**Risk**: [Description]
|
||||
- **Impact**: [High/Medium/Low - effect on project]
|
||||
- **Likelihood**: [High/Medium/Low]
|
||||
- **Mitigation**: [How to address]
|
||||
- **Fallback**: [Plan B if mitigation fails]
|
||||
|
||||
## Dependency Risks
|
||||
[External dependencies, blocking issues]
|
||||
|
||||
## Scope Risks
|
||||
[Scope creep, underestimation, unclear requirements]
|
||||
|
||||
</risks>
|
||||
|
||||
---
|
||||
|
||||
<appendix>
|
||||
## References
|
||||
[Papers, documentation, similar systems]
|
||||
|
||||
## Glossary
|
||||
[Domain-specific terms]
|
||||
|
||||
## Open Questions
|
||||
[Things to resolve during development]
|
||||
</appendix>
|
||||
|
||||
---
|
||||
|
||||
<task-master-integration>
|
||||
# How Task Master Uses This PRD
|
||||
|
||||
When you run `task-master parse-prd <file>.txt`, the parser:
|
||||
|
||||
1. **Extracts capabilities** → Main tasks
|
||||
- Each `### Capability:` becomes a top-level task
|
||||
|
||||
2. **Extracts features** → Subtasks
|
||||
- Each `#### Feature:` becomes a subtask under its capability
|
||||
|
||||
3. **Parses dependencies** → Task dependencies
|
||||
- `Depends on: [X, Y]` sets task.dependencies = ["X", "Y"]
|
||||
|
||||
4. **Orders by phases** → Task priorities
|
||||
- Phase 0 tasks = highest priority
|
||||
- Phase N tasks = lower priority, properly sequenced
|
||||
|
||||
5. **Uses test strategy** → Test generation context
|
||||
- Feeds test scenarios to Surgical Test Generator during implementation
|
||||
|
||||
**Result**: A dependency-aware task graph that can be executed in topological order.
|
||||
|
||||
## Why RPG Structure Matters
|
||||
|
||||
Traditional flat PRDs lead to:
|
||||
- ❌ Unclear task dependencies
|
||||
- ❌ Arbitrary task ordering
|
||||
- ❌ Circular dependencies discovered late
|
||||
- ❌ Poorly scoped tasks
|
||||
|
||||
RPG-structured PRDs provide:
|
||||
- ✅ Explicit dependency chains
|
||||
- ✅ Topological execution order
|
||||
- ✅ Clear module boundaries
|
||||
- ✅ Validated task graph before implementation
|
||||
|
||||
## Tips for Best Results
|
||||
|
||||
1. **Spend time on dependency graph** - This is the most valuable section for Task Master
|
||||
2. **Keep features atomic** - Each feature should be independently testable
|
||||
3. **Progressive refinement** - Start broad, use `task-master expand` to break down complex tasks
|
||||
4. **Use research mode** - `task-master parse-prd --research` leverages AI for better task generation
|
||||
</task-master-integration>
|
||||
+34
-9
@@ -92,8 +92,20 @@ async def list_sources(request: Request):
|
||||
|
||||
|
||||
@router.get("/source/{source_id}/chunks")
|
||||
async def source_chunks(source_id: int, request: Request):
|
||||
"""Browse mode: return all chunks of a single source, ordered."""
|
||||
async def source_chunks(
|
||||
source_id: int,
|
||||
request: Request,
|
||||
around: int | None = None,
|
||||
ctx: int = 2,
|
||||
):
|
||||
"""Browse mode: return chunks of a single source, ordered.
|
||||
|
||||
By default returns all chunks. With `around=<chunk_index>&ctx=<k>` it
|
||||
returns only chunks with chunk_index in [around-k, around+k] inclusive,
|
||||
so the search UI can show a matched chunk together with its surrounding
|
||||
sections for context (instead of duplicating the same chunk in both
|
||||
panes when the source has no PDF).
|
||||
"""
|
||||
_verify_auth(request)
|
||||
from api.services.kb.db import get_pool
|
||||
pool = await get_pool()
|
||||
@@ -105,13 +117,26 @@ async def source_chunks(source_id: int, request: Request):
|
||||
)
|
||||
if not source:
|
||||
raise HTTPException(status_code=404, detail="source not found")
|
||||
chunks = await conn.fetch(
|
||||
"""
|
||||
SELECT chunk_index, heading_path, section_ref, content, token_count
|
||||
FROM kb_chunk WHERE source_id = $1 ORDER BY chunk_index
|
||||
""",
|
||||
source_id,
|
||||
)
|
||||
if around is not None:
|
||||
ctx = max(0, min(ctx, 10))
|
||||
chunks = await conn.fetch(
|
||||
"""
|
||||
SELECT chunk_index, heading_path, section_ref, content, token_count
|
||||
FROM kb_chunk
|
||||
WHERE source_id = $1
|
||||
AND chunk_index BETWEEN $2 AND $3
|
||||
ORDER BY chunk_index
|
||||
""",
|
||||
source_id, around - ctx, around + ctx,
|
||||
)
|
||||
else:
|
||||
chunks = await conn.fetch(
|
||||
"""
|
||||
SELECT chunk_index, heading_path, section_ref, content, token_count
|
||||
FROM kb_chunk WHERE source_id = $1 ORDER BY chunk_index
|
||||
""",
|
||||
source_id,
|
||||
)
|
||||
src = dict(source)
|
||||
if src.get("published_at") is not None:
|
||||
src["published_at"] = src["published_at"].isoformat()
|
||||
|
||||
@@ -79,7 +79,7 @@ async def _retrieve_rrf(
|
||||
) u GROUP BY id
|
||||
)
|
||||
SELECT
|
||||
c.id AS chunk_id,
|
||||
c.id AS chunk_id, c.chunk_index,
|
||||
s.id AS source_id, s.kind, s.title, s.identifier, s.source_url,
|
||||
s.published_at, s.effective_at, s.original_path,
|
||||
c.heading_path, c.section_ref, c.content, c.page_number,
|
||||
|
||||
@@ -49,7 +49,9 @@ TOOL_RULES = (
|
||||
"- CALL vs MEETING: When user reports they spoke/talked/called someone (שוחחתי, דיברתי, התקשרתי) — use create_call. When user reports a physical meeting or Zoom (נפגשתי, פגישה) — use create_meeting. NEVER use create_meeting for phone calls.\n"
|
||||
"- OPEN QUESTIONS: If you asked the user a question and they did not answer it, repeat the question at the beginning of your next response. Track open questions until answered.\n"
|
||||
"- BEHAVIORAL RULES: If assistantRules are provided in the context, you MUST follow them. When user asks to set a persistent rule (\"from now on always...\", \"whenever I say X do Y\"), use save_rule to save it.\n"
|
||||
"- DOCUMENTS: When user asks to summarize, analyze, or read a document — first use list_documents to see what files exist, then use read_document with the file path to extract the text.\n"
|
||||
"- DOCUMENTS: Start with list_documents. If it shows files, use read_document / read_multiple_documents with the file paths.\n"
|
||||
"- DOCUMENT DISCOVERY: If list_documents returns 'No documents' with a diagnostic, read the diagnostic. If the folder path is wrong/missing, call find_case_folder(query=<contact name or case number>) to search storage, pick the best match, then call set_case_folder_path(path=...) to persist it, then list_documents(refresh=true). Use browse_folder(path=...) only as a manual override when find_case_folder doesn't surface the right match.\n"
|
||||
"- NEVER tell the user 'no documents' without first running find_case_folder — the folder might just be mis-mapped.\n"
|
||||
"- When user asks to summarize multiple documents or the entire case folder — use read_multiple_documents with all relevant file paths.\n"
|
||||
"- When user asks to rename or organize files — use batch_rename_documents with an array of rename operations.\n"
|
||||
"- TEMPLATE GENERATION: When user asks to generate/create a document from a template — use generate_from_template. The templateId comes from availableTemplates in your context.\n"
|
||||
@@ -101,6 +103,15 @@ def build_case_prompt(context: dict, user_profile: str = "", case_memory_notes:
|
||||
docs_section += f'\n - {fi["name"]} (path: {fi["path"]})'
|
||||
else:
|
||||
docs_section = "\n\n=== DOCUMENTS ===\nNo documents"
|
||||
resolved_path = documents.get("resolvedPath")
|
||||
path_source = documents.get("pathSource")
|
||||
folder_exists = documents.get("folderExists")
|
||||
diagnostic = documents.get("diagnostic")
|
||||
if resolved_path or diagnostic:
|
||||
docs_section += f"\nResolvedPath: {resolved_path or '(none)'} | Source: {path_source or '(none)'} | FolderExists: {folder_exists}"
|
||||
if diagnostic:
|
||||
docs_section += f"\nDiagnostic: {diagnostic}"
|
||||
docs_section += "\nRecovery: call list_documents(refresh=true) after a path change, or find_case_folder(query=...) to locate the folder and set_case_folder_path(path=...) to persist it."
|
||||
|
||||
# Memory section
|
||||
ms = case_memory.get("_summary", {})
|
||||
|
||||
@@ -0,0 +1,118 @@
|
||||
---
|
||||
name: medical-case-analysis
|
||||
description: ניתוח מסמכים רפואיים בתיק וגיבוש סיפור מקרה מובנה שניתן להעביר ל-law-mate להכנת כתב תביעה או ערעור
|
||||
version: 1.0.0
|
||||
---
|
||||
|
||||
# ניתוח רפואי של תיק → סיפור מקרה ל-law-mate
|
||||
|
||||
## מתי להשתמש
|
||||
|
||||
- המשתמש מבקש לעבור על המסמכים הרפואיים בתיק.
|
||||
- המשתמש אומר "תנתחי את התיק הרפואי", "תכיני לי סיפור מקרה", "תעבירי ל-law-mate", "תבדקי את הוועדות הרפואיות".
|
||||
- מדובר בתיקי נכות, תאונות, ביטוח לאומי, ביטוח פרטי, רשלנות רפואית, או כל תיק שבו יש חוות דעת / ועדות / תיק רפואי.
|
||||
|
||||
**אין להפעיל את ה-skill הזה אוטומטית בכל שיחה על תיק** — רק כשהמשתמש מבקש במפורש.
|
||||
|
||||
## שלב 1 — גילוי המסמכים
|
||||
|
||||
הרץ `list_documents`.
|
||||
|
||||
- **אם יש מסמכים:** המשך לשלב 2.
|
||||
- **אם אין מסמכים (totalFiles=0):** קרא את ה-`Diagnostic` בהודעה. אל תגיד למשתמש "אין מסמכים" מבלי לנסות לחפש.
|
||||
1. הרץ `find_case_folder` עם שם איש הקשר הראשי (מה-context `contacts[0].name`) או עם מספר התיק.
|
||||
2. אם יש התאמה אחת ברורה (score ≥ 80) — הצג אותה למשתמש ושאל "האם זו התיקייה של התיק?".
|
||||
3. אם יש כמה התאמות — הצג טבלה קצרה ובקש לבחור.
|
||||
4. אחרי אישור: `set_case_folder_path(path=...)` ואז `list_documents(refresh=true)`.
|
||||
|
||||
## שלב 2 — סינון המסמכים הרפואיים
|
||||
|
||||
עבור על רשימת המסמכים. סווג כ"רפואי" כל קובץ ששמו כולל אחד מהבאים (לא רגיש לאותיות, עברית/אנגלית):
|
||||
|
||||
| קטגוריה | מילות מפתח |
|
||||
|---|---|
|
||||
| ועדות רפואיות | ועדה, ועדת ערר, פרוטוקול ועדה, committee |
|
||||
| חוות דעת רפואיות | חוות דעת, חו"ד, חו״ד, opinion |
|
||||
| תיק קופ"ח / בי"ח | סיכום אשפוז, discharge, שחרור, תיק רפואי, קופ"ח, מאוחדת, כללית, מכבי, לאומית |
|
||||
| בדיקות | בדיקה, MRI, CT, רנטגן, אולטרסאונד, ultrasound, EMG |
|
||||
| ביטוח לאומי | ביטוח לאומי, בל"ל, החלטה, ועדה רפואית מל"ל |
|
||||
| אחר רפואי | רופא, תעודה רפואית, דו"ח, אישור מחלה |
|
||||
|
||||
הצג למשתמש את הרשימה המסוננת וכמה מסמכים שאין בה, ובקש אישור לפני קריאה (כדי לא לחרוג ב-tokens).
|
||||
|
||||
## שלב 3 — קריאה וחילוץ
|
||||
|
||||
`read_multiple_documents(filePaths=[...])` על כל המסמכים הרפואיים שסווגו. אם הרשימה ארוכה מ-10 קבצים — חלק לבאטצ'ים של 5-7 ושמור סיכומי ביניים ב-`save_case_memory` עם `category="documents_notes"`.
|
||||
|
||||
לכל מסמך, חלץ ל-working notes:
|
||||
|
||||
- **תאריך המסמך** (מהמסמך עצמו; אם חסר — ציין "לא מצוין").
|
||||
- **מקור** (שם בית חולים / קופ"ח / רופא / ועדה).
|
||||
- **אבחנה/ממצא עיקרי** (במילים של המסמך, לא פרשנות שלך).
|
||||
- **אחוזי נכות / אובדן כושר** אם מופיעים (כולל צירוף אחוזים, זמני/קבוע).
|
||||
- **המלצות טיפוליות / פעולות שדורשות המשך** אם מופיעות.
|
||||
- **ציטוט מפתח** אחד קצר (כדי שיהיה מה להצמיד לכתב התביעה).
|
||||
|
||||
## שלב 4 — שאלות מובנות למשתמש
|
||||
|
||||
לפני שכותבים סיפור מקרה, צריך מידע שלא נמצא במסמכים הרפואיים. שאל את המשתמש בסדר הזה, **שאלה אחת בכל פעם** (אל תציף):
|
||||
|
||||
1. **נסיבות:** "מה הנסיבות המדויקות של האירוע / התאונה / תחילת המצב הרפואי? תאריך, מקום, מי היה מעורב."
|
||||
2. **תלונות סובייקטיביות:** "אילו כאבים / מגבלות / סימפטומים הלקוח מדווח עליהם היום?"
|
||||
3. **השפעה תפקודית:** "איך זה משפיע על חיי היומיום? עבודה, שינה, טיפול עצמי, חיי משפחה."
|
||||
4. **טיפול נוכחי:** "איזה טיפול רפואי הוא מקבל כרגע? תרופות, פיזיותרפיה, מעקב?"
|
||||
5. **מצב קודם:** "האם היו מחלות / פציעות קודמות רלוונטיות לאותו אזור?"
|
||||
6. **מסמכים חסרים:** הצג רשימת מסמכים שחסרים לפי מה שהיית מצפה לראות (לדוגמה: "לא מצאתי חוות דעת עדכנית מרופא אורתופד — יש כזו?").
|
||||
|
||||
אחרי כל תשובה — שמור דרך `save_case_memory(category="key_facts", ...)`.
|
||||
|
||||
## שלב 5 — סיפור מקרה (הפלט ל-law-mate)
|
||||
|
||||
אחרי השאלות, הצג למשתמש סיכום בפורמט הזה (markdown, בעברית, ישיר — זה הטקסט שיועתק ל-law-mate):
|
||||
|
||||
```markdown
|
||||
# סיפור מקרה — [שם הלקוח] (תיק #[מספר])
|
||||
|
||||
## 1. נסיבות האירוע
|
||||
[פסקה של 3-5 משפטים בהתבסס על תשובת המשתמש לשאלה 1]
|
||||
|
||||
## 2. ציר זמן רפואי
|
||||
| תאריך | גורם | ממצא/אבחנה |
|
||||
|---|---|---|
|
||||
| ... | ... | ... |
|
||||
|
||||
## 3. ממצאים רפואיים מרכזיים
|
||||
- [ממצא 1] — [מקור, ציטוט קצר]
|
||||
- [ממצא 2] — ...
|
||||
- [אחוזי נכות שנקבעו, אם יש]
|
||||
|
||||
## 4. תלונות סובייקטיביות והשפעה תפקודית
|
||||
[3-4 שורות מתשובות המשתמש לשאלות 2-3]
|
||||
|
||||
## 5. טיפול נוכחי
|
||||
[תשובת המשתמש לשאלה 4]
|
||||
|
||||
## 6. טענות משפטיות אפשריות (לבדיקה ב-law-mate)
|
||||
- [שאלה משפטית 1 — לדוגמה: "האם מוצדק ערעור על 20% נכות?"]
|
||||
- [שאלה משפטית 2]
|
||||
|
||||
## 7. מסמכים שעדיין חסרים
|
||||
- [רשימה]
|
||||
|
||||
## 8. ציטוטים מרכזיים מהמסמכים הרפואיים
|
||||
> "..."
|
||||
> — [שם המסמך, תאריך]
|
||||
```
|
||||
|
||||
אחרי הצגת הסיכום, שאל את המשתמש: "להעתיק ל-law-mate? או שיש משהו להוסיף/לתקן?"
|
||||
|
||||
## שלב 6 — שמירה לזיכרון התיק
|
||||
|
||||
בסוף, שמור את הסיפור כ-`save_case_memory(category="strategy", name="סיפור מקרה לניתוח ב-law-mate", content=<הסיפור המלא>, importance="high")` כדי שהשיחה הבאה תוכל להמשיך מאותה נקודה.
|
||||
|
||||
## כללים ואזהרות
|
||||
|
||||
- **אל תמציא ממצאים רפואיים**. אם משהו לא כתוב במסמכים — ציין "לא מצוין במסמכים" במקום לנחש.
|
||||
- **אל תחרוג לפרשנות משפטית עצמאית** — מטרת ה-skill היא להכין את החומר ל-law-mate שיעשה את הניתוח.
|
||||
- **אחוזי נכות** — הצג תמיד כפי שהם כתובים במסמך (למשל "20% נכות כללית זמנית עד 31/12/2026"), לא כמספר בודד.
|
||||
- **שפה** — עברית בלבד בפלט ובשיחה עם המשתמש.
|
||||
Reference in New Issue
Block a user