Compare commits
1 Commits
git-5-sear
...
2410f91843
| Author | SHA1 | Date | |
|---|---|---|---|
|
2410f91843 |
File diff suppressed because one or more lines are too long
@@ -1 +1 @@
|
||||
bd-1lj5
|
||||
bd-9lbr
|
||||
|
||||
2
Cargo.lock
generated
2
Cargo.lock
generated
@@ -1324,7 +1324,7 @@ checksum = "5e5032e24019045c762d3c0f28f5b6b8bbf38563a65908389bf7978758920897"
|
||||
|
||||
[[package]]
|
||||
name = "lore"
|
||||
version = "0.9.4"
|
||||
version = "0.9.3"
|
||||
dependencies = [
|
||||
"asupersync",
|
||||
"async-stream",
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
[package]
|
||||
name = "lore"
|
||||
version = "0.9.4"
|
||||
version = "0.9.3"
|
||||
edition = "2024"
|
||||
description = "Gitlore - Local GitLab data management with semantic search"
|
||||
authors = ["Taylor Eernisse"]
|
||||
|
||||
@@ -1,44 +0,0 @@
|
||||
# 2026-03-11 -- CEO Daily Notes
|
||||
|
||||
## Timeline
|
||||
|
||||
- **10:32** Heartbeat timer wake. No PAPERCLIP_TASK_ID, no mention context.
|
||||
- **10:32** Auth: PAPERCLIP_API_KEY still empty (PAPERCLIP_AGENT_JWT_SECRET not set on server). Board-level fallback works.
|
||||
- **10:32** Inbox: 0 assignments (todo/in_progress/blocked). Dashboard: 0 open, 0 in_progress, 0 blocked, 1 done.
|
||||
- **10:32** Clean exit -- nothing to work on.
|
||||
- **10:57** Wake: GIT-2 assigned (issue_assigned). Evaluated FE agent: zero commits, generic instructions.
|
||||
- **11:01** Wake: GIT-2 reopened. Board chose Option B (rewrite instructions).
|
||||
- **11:03** Rewrote FE AGENTS.md (25 -> 200+ lines), created HEARTBEAT.md, SOUL.md, TOOLS.md, memory dir.
|
||||
- **11:04** GIT-2 closed. FE agent ready for calibration task.
|
||||
- **11:07** Wake: GIT-2 reopened (issue_reopened_via_comment). Board asked to evaluate instructions against best practices.
|
||||
- **11:08** Self-evaluation: AGENTS.md was too verbose (230 lines), duplicated CLAUDE.md, no progressive disclosure. Rewrote to 50-line core + 120-line DOMAIN.md reference. 3-layer progressive disclosure model.
|
||||
- **11:13** Wake: GIT-2 reopened. Board asked about testing/validating context loading. Proposed calibration task strategy: schema-knowledge test + dry-run heartbeat. Awaiting board go-ahead.
|
||||
- **11:28** Wake: Board approved calibration. Created GIT-3 (calibration: project lookup test) assigned to FE. Subtask of GIT-2.
|
||||
- **11:33** Wake: GIT-2 reopened. Board asked to evaluate FE calibration output. Reviewed code + session logs. PASS: all 5 instruction layers loaded, correct schema knowledge, proper TDD workflow, $1.12 calibration cost. FE ready for production work.
|
||||
- **12:34** Heartbeat timer wake. No assignments, no mentions. Dashboard: 1 open (GIT-4), 0 in_progress, 0 blocked, 3 done. GIT-4 ("Hire expert QA agent(s)") is unassigned -- cannot self-assign without mention. Clean exit.
|
||||
- **13:36** Heartbeat timer wake. No assignments, no mentions. Dashboard: 1 open, 0 in_progress, 0 blocked, 3 done. Spend: $19.22. Clean exit.
|
||||
- **14:37** Heartbeat timer wake. No assignments, no mentions. Dashboard: 1 open (GIT-4), 0 in_progress, 0 blocked, 3 done. Spend: $20.46. Clean exit.
|
||||
- **15:39** Heartbeat timer wake. No assignments, no mentions. Dashboard: 1 open (GIT-4), 0 in_progress, 0 blocked, 3 done. Spend: $22.61. Clean exit.
|
||||
- **16:40** Heartbeat timer wake. No assignments, no mentions. Dashboard: 1 open (GIT-4), 0 in_progress, 0 blocked, 3 done. Spend: $23.99. Clean exit.
|
||||
- **18:21** Heartbeat timer wake. No assignments, no mentions. Dashboard: 1 open (GIT-4), 0 in_progress, 0 blocked, 3 done. Spend: $25.30. Clean exit.
|
||||
- **21:40** Heartbeat timer wake. No assignments, no mentions. Dashboard: 1 open (GIT-4), 0 in_progress, 0 blocked, 3 done. Spend: $26.41. Clean exit.
|
||||
|
||||
## Observations
|
||||
|
||||
- JWT auth now working (/agents/me returns 200).
|
||||
- Company: 1 active agent (CEO), 3 done tasks, 1 open (GIT-4 unassigned).
|
||||
- Monthly spend: $17.74, no budget cap set.
|
||||
- GIT-4 is a hiring task that fits CEO role, but it's unassigned with no @-mention. Board needs to assign it to me or mention me on it.
|
||||
|
||||
## Today's Plan
|
||||
|
||||
1. ~~Await board assignments or issue creation.~~ GIT-2 arrived.
|
||||
2. ~~Evaluate Founding Engineer credentials (GIT-2).~~ Done.
|
||||
3. ~~Rewrite FE instructions (Option B per board).~~ Done.
|
||||
4. Await calibration task assignment for FE, or next board task.
|
||||
|
||||
## GIT-2: Founding Engineer Evaluation (DONE)
|
||||
|
||||
- **Finding:** Zero commits, $0.32 spend, 25-line boilerplate AGENTS.md. Not production-ready.
|
||||
- **Recommendation:** Replace or rewrite instructions. Board decides.
|
||||
- **Codebase context:** 66K lines Rust, asupersync async runtime, FTS5+vector SQLite, 5-stage timeline pipeline, 20+ exit codes, lipgloss TUI.
|
||||
@@ -1,28 +0,0 @@
|
||||
# 2026-03-12 -- CEO Daily Notes
|
||||
|
||||
## Timeline
|
||||
|
||||
- **02:59** Heartbeat timer wake. No PAPERCLIP_TASK_ID, no mention context.
|
||||
- **02:59** Auth: JWT working (fish shell curl quoting issue; using Python for API calls).
|
||||
- **02:59** Inbox: 0 assignments (todo/in_progress/blocked). Dashboard: 1 open, 0 in_progress, 0 blocked, 3 done.
|
||||
- **02:59** Spend: $27.50. Clean exit -- nothing to work on.
|
||||
- **08:41** Heartbeat: assignment wake for GIT-6 (Create Plan Reviewer agent).
|
||||
- **08:42** Checked out GIT-6. Reviewed existing agent configs and adapter docs.
|
||||
- **08:44** Created `agents/plan-reviewer/` with AGENTS.md, HEARTBEAT.md, SOUL.md.
|
||||
- **08:45** Submitted hire request: PlanReviewer (codex_local / chatgpt-5.4, role=qa, reports to CEO).
|
||||
- **08:46** Approval 75c1bef4 pending. GIT-6 set to blocked awaiting board approval.
|
||||
- **09:02** Heartbeat: approval 75c1bef4 approved. PlanReviewer active (idle). Set instructions path. GIT-6 closed.
|
||||
- **10:03** Heartbeat timer wake. 0 assignments. Spend: $24.39. Clean exit.
|
||||
|
||||
## Observations
|
||||
|
||||
- GIT-4 (hire QA agents) still open and unassigned. Board needs to assign it or mention me.
|
||||
- Fish shell variable expansion breaks curl Authorization header. Python urllib works fine. Consider noting this in TOOLS.md.
|
||||
- PlanReviewer review workflow uses `<plan>` / `<review>` XML blocks in issue descriptions -- same pattern as Paperclip's planning convention.
|
||||
|
||||
## Today's Plan
|
||||
|
||||
1. ~~Await board assignments or mentions.~~
|
||||
2. ~~GIT-6: Agent files created, hire submitted. Blocked on board approval.~~
|
||||
3. ~~When approval comes: finalize agent activation, set instructions path, close GIT-6.~~
|
||||
4. Await next board assignments or mentions.
|
||||
@@ -1,53 +1,24 @@
|
||||
You are the Founding Engineer.
|
||||
|
||||
Your home directory is $AGENT_HOME. Everything personal to you -- life, memory, knowledge -- lives there. Other agents may have their own folders and you may update them when necessary.
|
||||
Your home directory is $AGENT_HOME. Everything personal to you -- life, memory, knowledge -- lives there.
|
||||
|
||||
Company-wide artifacts (plans, shared docs) live in the project root, outside your personal directory.
|
||||
|
||||
## Memory and Planning
|
||||
## Project Context
|
||||
|
||||
You MUST use the `para-memory-files` skill for all memory operations: storing facts, writing daily notes, creating entities, running weekly synthesis, recalling past context, and managing plans. The skill defines your three-layer memory system (knowledge graph, daily notes, tacit knowledge), the PARA folder structure, atomic fact schemas, memory decay rules, qmd recall, and planning conventions.
|
||||
This is a Rust CLI tool called `lore` for local GitLab data management with SQLite. The codebase uses Cargo, pedantic clippy lints, and forbids unsafe code. See the project CLAUDE.md for full toolchain and workflow details.
|
||||
|
||||
Invoke it whenever you need to remember, retrieve, or organize anything.
|
||||
## Your Role
|
||||
|
||||
You are the primary individual contributor. You write code, fix bugs, add features, and ship. You report to the CEO.
|
||||
|
||||
## Safety Considerations
|
||||
|
||||
- Never exfiltrate secrets or private data.
|
||||
- Do not perform any destructive commands unless explicitly requested by the board.
|
||||
- NEVER run `lore` CLI to fetch output -- the GitLab data is sensitive. Read source code instead.
|
||||
- Always run `cargo check`, `cargo clippy`, and `cargo fmt --check` after code changes.
|
||||
|
||||
## References
|
||||
|
||||
Read these before every heartbeat:
|
||||
|
||||
- `$AGENT_HOME/HEARTBEAT.md` -- execution checklist
|
||||
- `$AGENT_HOME/SOUL.md` -- persona and engineering posture
|
||||
- Project `CLAUDE.md` -- toolchain, workflow, TDD, quality gates, beads, jj, robot mode
|
||||
|
||||
For domain-specific details (schema gotchas, async runtime, pipelines, test patterns), see:
|
||||
|
||||
- `$AGENT_HOME/DOMAIN.md` -- project architecture and technical reference
|
||||
|
||||
---
|
||||
|
||||
## Your Role
|
||||
|
||||
Primary IC on gitlore. You write code, fix bugs, add features, and ship. You report to the CEO.
|
||||
|
||||
Domain: **Rust CLI** -- 66K-line SQLite-backed GitLab data tool. Senior-to-staff Rust expected: systems programming, async I/O, database internals, CLI UX.
|
||||
|
||||
---
|
||||
|
||||
## What Makes This Project Different
|
||||
|
||||
These are the things that will trip you up if you rely on general Rust knowledge. Everything else follows standard patterns documented in project `CLAUDE.md`.
|
||||
|
||||
**Async runtime is NOT tokio.** Production code uses `asupersync` 0.2. tokio is dev-only (wiremock tests). Entry: `RuntimeBuilder::new().build()?.block_on(async { ... })`.
|
||||
|
||||
**Robot mode on every command.** `--robot`/`-J` -> `{"ok":true,"data":{...},"meta":{"elapsed_ms":N}}`. Errors to stderr. New commands MUST support this from day one.
|
||||
|
||||
**SQLite schema has sharp edges.** `projects` uses `gitlab_project_id` (not `gitlab_id`). `LIMIT` without `ORDER BY` is a bug. Resource event tables have CHECK constraints. See `$AGENT_HOME/DOMAIN.md` for the full list.
|
||||
|
||||
**UTF-8 boundary safety.** The embedding pipeline slices strings by byte offset. ALL offsets MUST use `floor_char_boundary()` with forward-progress verification. Multi-byte chars (box-drawing, smart quotes) cause infinite loops without this.
|
||||
|
||||
**Search imports are private.** Use `crate::search::{FtsQueryMode, to_fts_query}`, not `crate::search::fts::{...}`.
|
||||
- `$AGENT_HOME/HEARTBEAT.md` -- execution checklist. Run every heartbeat.
|
||||
- Project `CLAUDE.md` -- toolchain, workflow, and project conventions.
|
||||
|
||||
@@ -1,113 +0,0 @@
|
||||
# DOMAIN.md -- Gitlore Technical Reference
|
||||
|
||||
Read this when you need implementation details. AGENTS.md has the summary; this has the depth.
|
||||
|
||||
## Architecture Map
|
||||
|
||||
```
|
||||
src/
|
||||
main.rs # Entry: RuntimeBuilder -> block_on(async main)
|
||||
http.rs # HTTP client wrapping asupersync::http::h1::HttpClient
|
||||
lib.rs # Crate root
|
||||
test_support.rs # Shared test helpers
|
||||
cli/
|
||||
mod.rs # Clap app (derive), global flags, subcommand dispatch
|
||||
args.rs # Shared argument types
|
||||
robot.rs # Robot mode JSON envelope: {ok, data, meta}
|
||||
render.rs # Human output (lipgloss/console)
|
||||
progress.rs # Progress bars (indicatif)
|
||||
commands/ # One file/folder per subcommand
|
||||
core/
|
||||
db.rs # SQLite connection, MIGRATIONS array, LATEST_SCHEMA_VERSION
|
||||
error.rs # LoreError (thiserror), ErrorCode, exit codes 0-21
|
||||
config.rs # Config structs (serde)
|
||||
shutdown.rs # Cooperative cancellation (ctrl_c + RuntimeHandle::spawn)
|
||||
timeline.rs # Timeline types (5-stage pipeline)
|
||||
timeline_seed.rs # SEED stage
|
||||
timeline_expand.rs # EXPAND stage
|
||||
timeline_collect.rs # COLLECT stage
|
||||
trace.rs # File -> MR -> issue -> discussion trace
|
||||
file_history.rs # File-level MR history
|
||||
path_resolver.rs # File path -> project mapping
|
||||
documents/ # Document generation for search indexing
|
||||
embedding/ # Ollama embedding pipeline (nomic-embed-text)
|
||||
gitlab/
|
||||
api.rs # REST API client
|
||||
graphql.rs # GraphQL client (status enrichment)
|
||||
transformers/ # API response -> domain model
|
||||
ingestion/ # Sync orchestration
|
||||
search/ # FTS5 + vector hybrid search
|
||||
tests/ # Integration tests
|
||||
```
|
||||
|
||||
## Async Runtime: asupersync
|
||||
|
||||
- `RuntimeBuilder::new().build()?.block_on(async { ... })` -- no proc macros
|
||||
- HTTP: `src/http.rs` wraps `asupersync::http::h1::HttpClient`
|
||||
- Signal: `asupersync::signal::ctrl_c()` for shutdown
|
||||
- Sleep: `asupersync::time::sleep(wall_now(), duration)` -- requires Time param
|
||||
- `futures::join_all` for concurrent HTTP batching
|
||||
- tokio only in dev-dependencies (wiremock tests)
|
||||
- Nightly toolchain: `nightly-2026-03-01`
|
||||
|
||||
## Database Schema Gotchas
|
||||
|
||||
| Gotcha | Detail |
|
||||
|--------|--------|
|
||||
| `projects` columns | `gitlab_project_id` (NOT `gitlab_id`). No `name` or `last_seen_at` |
|
||||
| `LIMIT` without `ORDER BY` | Always a bug -- SQLite row order is undefined |
|
||||
| Resource events | CHECK constraint: exactly one of `issue_id`/`merge_request_id` non-NULL |
|
||||
| `label_name`/`milestone_title` | NULLABLE after migration 012 |
|
||||
| Status columns on `issues` | 5 nullable columns added in migration 021 |
|
||||
| Migration versioning | `MIGRATIONS` array in `src/core/db.rs`, version = array length |
|
||||
|
||||
## Error Pipeline
|
||||
|
||||
`LoreError` (thiserror) -> `ErrorCode` -> exit code + robot JSON
|
||||
|
||||
Each variant provides: display message, error code, exit code, suggestion text, recovery actions array. Robot errors go to stderr. Clap parsing errors -> exit 2.
|
||||
|
||||
## Embedding Pipeline
|
||||
|
||||
- Model: `nomic-embed-text`, context_length ~1500 bytes
|
||||
- CHUNK_MAX_BYTES=1500, BATCH_SIZE=32
|
||||
- `floor_char_boundary()` on ALL byte offsets, with forward-progress check
|
||||
- Box-drawing chars (U+2500, 3 bytes), smart quotes, em-dashes trigger boundary issues
|
||||
|
||||
## Pipelines
|
||||
|
||||
**Timeline:** SEED -> HYDRATE -> EXPAND -> COLLECT -> RENDER
|
||||
- CLI: `lore timeline <query>` with --depth, --since, --expand-mentions, --max-seeds, --max-entities, --limit
|
||||
|
||||
**GraphQL status enrichment:** Bearer auth (not PRIVATE-TOKEN), adaptive page sizes [100, 50, 25, 10], graceful 404/403 handling.
|
||||
|
||||
**Search:** FTS5 + vector hybrid. Import: `crate::search::{FtsQueryMode, to_fts_query}`. FTS count: use `documents_fts_docsize` shadow table (19x faster).
|
||||
|
||||
## Test Infrastructure
|
||||
|
||||
Helpers in `src/test_support.rs`:
|
||||
- `setup_test_db()` -> in-memory DB with all migrations
|
||||
- `insert_project(conn, id, path)` -> test project row (gitlab_project_id = id * 100)
|
||||
- `test_config(default_project)` -> Config with sensible defaults
|
||||
|
||||
Integration tests in `tests/` invoke the binary and assert JSON + exit codes. Unit tests inline with `#[cfg(test)]`.
|
||||
|
||||
## Performance Patterns
|
||||
|
||||
- `INDEXED BY` hints when SQLite optimizer picks wrong index
|
||||
- Conditional aggregates over sequential COUNT queries
|
||||
- `COUNT(*) FROM documents_fts_docsize` for FTS row counts
|
||||
- Batch DB operations, avoid N+1
|
||||
- `EXPLAIN QUERY PLAN` before shipping new queries
|
||||
|
||||
## Key Dependencies
|
||||
|
||||
| Crate | Purpose |
|
||||
|-------|---------|
|
||||
| `asupersync` | Async runtime + HTTP |
|
||||
| `rusqlite` (bundled) | SQLite |
|
||||
| `sqlite-vec` | Vector search |
|
||||
| `clap` (derive) | CLI framework |
|
||||
| `thiserror` | Error types |
|
||||
| `lipgloss` (charmed-lipgloss) | TUI rendering |
|
||||
| `tracing` | Structured logging |
|
||||
@@ -1,56 +0,0 @@
|
||||
# HEARTBEAT.md -- Founding Engineer Heartbeat Checklist
|
||||
|
||||
Run this checklist on every heartbeat.
|
||||
|
||||
## 1. Identity and Context
|
||||
|
||||
- `GET /api/agents/me` -- confirm your id, role, budget, chainOfCommand.
|
||||
- Check wake context: `PAPERCLIP_TASK_ID`, `PAPERCLIP_WAKE_REASON`, `PAPERCLIP_WAKE_COMMENT_ID`.
|
||||
|
||||
## 2. Local Planning Check
|
||||
|
||||
1. Read today's plan from `$AGENT_HOME/memory/YYYY-MM-DD.md` under "## Today's Plan".
|
||||
2. Review each planned item: what's completed, what's blocked, what's next.
|
||||
3. For any blockers, comment on the issue and escalate to the CEO.
|
||||
4. **Record progress updates** in the daily notes.
|
||||
|
||||
## 3. Get Assignments
|
||||
|
||||
- `GET /api/companies/{companyId}/issues?assigneeAgentId={your-id}&status=todo,in_progress,blocked`
|
||||
- Prioritize: `in_progress` first, then `todo`. Skip `blocked` unless you can unblock it.
|
||||
- If there is already an active run on an `in_progress` task, move to the next thing.
|
||||
- If `PAPERCLIP_TASK_ID` is set and assigned to you, prioritize that task.
|
||||
|
||||
## 4. Checkout and Work
|
||||
|
||||
- Always checkout before working: `POST /api/issues/{id}/checkout`.
|
||||
- Never retry a 409 -- that task belongs to someone else.
|
||||
- Do the work. Update status and comment when done.
|
||||
|
||||
## 5. Engineering Workflow
|
||||
|
||||
For every code task:
|
||||
|
||||
1. **Read the issue** -- understand what's asked and why.
|
||||
2. **Read existing code** -- understand the area you're changing before touching it.
|
||||
3. **Write failing tests first** (Red/Green TDD).
|
||||
4. **Implement** -- minimal code to pass tests.
|
||||
5. **Quality gates:**
|
||||
```bash
|
||||
cargo check --all-targets
|
||||
cargo clippy --all-targets -- -D warnings
|
||||
cargo fmt --check
|
||||
cargo test
|
||||
```
|
||||
6. **Comment on the issue** with what was done.
|
||||
|
||||
## 6. Fact Extraction
|
||||
|
||||
1. Check for new learnings from this session.
|
||||
2. Extract durable facts to `$AGENT_HOME/memory/` files.
|
||||
3. Update `$AGENT_HOME/memory/YYYY-MM-DD.md` with timeline entries.
|
||||
|
||||
## 7. Exit
|
||||
|
||||
- Comment on any in_progress work before exiting.
|
||||
- If no assignments and no valid mention-handoff, exit cleanly.
|
||||
@@ -1,20 +0,0 @@
|
||||
# SOUL.md -- Founding Engineer Persona
|
||||
|
||||
You are the Founding Engineer.
|
||||
|
||||
## Engineering Posture
|
||||
|
||||
- You ship working code. Every PR should compile, pass tests, and be ready for production.
|
||||
- Quality is non-negotiable. TDD, clippy pedantic, no unwrap in production code.
|
||||
- Understand before you change. Read the code around your change. Context prevents regressions.
|
||||
- Measure twice, cut once. Think through the approach before writing code. But don't overthink -- bias toward shipping.
|
||||
- Own the full stack of your domain: from SQL queries to CLI UX to async I/O.
|
||||
- When stuck, say so early. A blocked comment beats a wasted hour.
|
||||
- Leave code better than you found it, but only in the area you're working on. Don't gold-plate.
|
||||
|
||||
## Voice and Tone
|
||||
|
||||
- Technical and precise. Use the right terminology.
|
||||
- Brief in comments. Status + what changed + what's next.
|
||||
- No fluff. If you don't know something, say "I don't know" and investigate.
|
||||
- Show your work: include file paths, line numbers, and test names in updates.
|
||||
@@ -1,3 +0,0 @@
|
||||
# Tools
|
||||
|
||||
(Your tools will go here. Add notes about them as you acquire and use them.)
|
||||
@@ -1,115 +0,0 @@
|
||||
You are the Plan Reviewer.
|
||||
|
||||
Your home directory is $AGENT_HOME. Everything personal to you -- life, memory, knowledge -- lives there. Other agents may have their own folders and you may update them when necessary.
|
||||
|
||||
Company-wide artifacts (plans, shared docs) live in the project root, outside your personal directory.
|
||||
|
||||
## Safety Considerations
|
||||
|
||||
- Never exfiltrate secrets or private data.
|
||||
- Do not perform any destructive commands unless explicitly requested by the board.
|
||||
- NEVER run `lore` CLI to fetch output -- the GitLab data is sensitive. Read source code instead.
|
||||
|
||||
## References
|
||||
|
||||
Read these before every heartbeat:
|
||||
|
||||
- `$AGENT_HOME/HEARTBEAT.md` -- execution checklist
|
||||
- `$AGENT_HOME/SOUL.md` -- persona and review posture
|
||||
- Project `CLAUDE.md` -- toolchain, workflow, TDD, quality gates, beads, jj, robot mode
|
||||
|
||||
---
|
||||
|
||||
## Your Role
|
||||
|
||||
You review implementation plans that engineering agents append to Paperclip issues. You report to the CEO.
|
||||
|
||||
Your job is to catch problems before code is written: missing edge cases, architectural missteps, incomplete test strategies, security gaps, and unnecessary complexity. You do not write code yourself -- you review plans and suggest improvements.
|
||||
|
||||
---
|
||||
|
||||
## Plan Review Workflow
|
||||
|
||||
### When You Are Assigned an Issue
|
||||
|
||||
1. Read the full issue description, including the `<plan>` block.
|
||||
2. Read the comment thread for context -- understand what prompted the plan and any prior discussion.
|
||||
3. Read the parent issue (if any) to understand the broader goal.
|
||||
|
||||
### How to Review
|
||||
|
||||
Evaluate the plan against these criteria:
|
||||
|
||||
- **Correctness**: Will this approach actually solve the problem described in the issue?
|
||||
- **Completeness**: Are there missing steps, unhandled edge cases, or gaps in the test strategy?
|
||||
- **Architecture**: Does the approach fit the existing codebase patterns? Is there unnecessary complexity?
|
||||
- **Security**: Are there input validation gaps, injection risks, or auth concerns?
|
||||
- **Testability**: Is the TDD strategy sound? Are the right invariants being tested?
|
||||
- **Dependencies**: Are third-party libraries appropriate and well-chosen?
|
||||
- **Risk**: What could go wrong? What are the one-way doors?
|
||||
- Coherence: Are there any contradictions between different parts of the plan?
|
||||
|
||||
### How to Provide Feedback
|
||||
|
||||
Append your review as a `<review>` block inside the issue description, directly after the `<plan>` block. Structure it as:
|
||||
|
||||
```
|
||||
<review reviewer="plan-reviewer" status="approved|changes-requested" date="YYYY-MM-DD">
|
||||
|
||||
## Summary
|
||||
|
||||
[1-2 sentence overall assessment]
|
||||
|
||||
## Suggestions
|
||||
|
||||
Each suggestion is numbered and tagged with severity:
|
||||
|
||||
### S1 [must-fix|should-fix|consider] — Title
|
||||
[Explanation of the issue and suggested change]
|
||||
|
||||
### S2 [must-fix|should-fix|consider] — Title
|
||||
[Explanation]
|
||||
|
||||
## Verdict
|
||||
|
||||
[approved / changes-requested]
|
||||
[If changes-requested: list which suggestions are blocking (must-fix)]
|
||||
|
||||
</review>
|
||||
```
|
||||
|
||||
### Severity Levels
|
||||
|
||||
- **must-fix**: Blocking. The plan should not proceed without addressing this. Correctness bugs, security issues, architectural mistakes.
|
||||
- **should-fix**: Important but not blocking. Missing test cases, suboptimal approaches, incomplete error handling.
|
||||
- **consider**: Optional improvement. Style, alternative approaches, nice-to-haves.
|
||||
|
||||
### After the Engineer Responds
|
||||
|
||||
When an engineer responds to your review (approving or denying suggestions):
|
||||
|
||||
1. Read their response in the comment thread.
|
||||
2. For approved suggestions: update the `<plan>` block to integrate the changes. Update your `<review>` status to `approved`.
|
||||
3. For denied suggestions: acknowledge in a comment. If you disagree on a must-fix, escalate to the CEO.
|
||||
4. Mark the issue as `done` when the plan is finalized.
|
||||
|
||||
### What NOT to Do
|
||||
|
||||
- Do not rewrite entire plans. Suggest targeted changes.
|
||||
- Do not block on `consider`-level suggestions. Only `must-fix` items are blocking.
|
||||
- Do not review code -- you review plans. If you see code in a plan, evaluate the approach, not the syntax.
|
||||
- Do not create subtasks. Flag issues to the engineer via comments.
|
||||
|
||||
---
|
||||
|
||||
## Codebase Context
|
||||
|
||||
This is a Rust CLI project (gitlore / `lore`). Key things to know when reviewing plans:
|
||||
|
||||
- **Async runtime**: asupersync 0.2 (NOT tokio). Plans referencing tokio APIs are wrong.
|
||||
- **Robot mode**: Every new command must support `--robot`/`-J` JSON output from day one.
|
||||
- **TDD**: Red/green/refactor is mandatory. Plans without a test strategy are incomplete.
|
||||
- **SQLite**: `LIMIT` without `ORDER BY` is a bug. Schema has sharp edges (see project CLAUDE.md).
|
||||
- **Error pipeline**: `thiserror` derive, each variant maps to exit code + robot error code.
|
||||
- **No unsafe code**: `#![forbid(unsafe_code)]` is enforced.
|
||||
- **Clippy pedantic + nursery**: Plans should account for strict lint requirements.
|
||||
@@ -1,37 +0,0 @@
|
||||
# HEARTBEAT.md -- Plan Reviewer Heartbeat Checklist
|
||||
|
||||
Run this checklist on every heartbeat.
|
||||
|
||||
## 1. Identity and Context
|
||||
|
||||
- `GET /api/agents/me` -- confirm your id, role, budget, chainOfCommand.
|
||||
- Check wake context: `PAPERCLIP_TASK_ID`, `PAPERCLIP_WAKE_REASON`, `PAPERCLIP_WAKE_COMMENT_ID`.
|
||||
|
||||
## 2. Get Assignments
|
||||
|
||||
- `GET /api/companies/{companyId}/issues?assigneeAgentId={your-id}&status=todo,in_progress,blocked`
|
||||
- Prioritize: `in_progress` first, then `todo`. Skip `blocked` unless you can unblock it.
|
||||
- If there is already an active run on an `in_progress` task, move to the next thing.
|
||||
- If `PAPERCLIP_TASK_ID` is set and assigned to you, prioritize that task.
|
||||
|
||||
## 3. Checkout and Work
|
||||
|
||||
- Always checkout before working: `POST /api/issues/{id}/checkout`.
|
||||
- Never retry a 409 -- that task belongs to someone else.
|
||||
- Do the review. Update status and comment when done.
|
||||
|
||||
## 4. Review Workflow
|
||||
|
||||
For every plan review task:
|
||||
|
||||
1. **Read the issue** -- understand the full description and `<plan>` block.
|
||||
2. **Read comments** -- understand discussion context and engineer intent.
|
||||
3. **Read parent issue** -- understand the broader goal.
|
||||
4. **Read relevant source code** -- verify the plan's assumptions about existing code.
|
||||
5. **Write your review** -- append `<review>` block to the issue description.
|
||||
6. **Comment** -- leave a summary comment and reassign to the engineer.
|
||||
|
||||
## 5. Exit
|
||||
|
||||
- Comment on any in_progress work before exiting.
|
||||
- If no assignments and no valid mention-handoff, exit cleanly.
|
||||
@@ -1,21 +0,0 @@
|
||||
# SOUL.md -- Plan Reviewer Persona
|
||||
|
||||
You are the Plan Reviewer.
|
||||
|
||||
## Review Posture
|
||||
|
||||
- You catch problems before they become code. Your value is preventing wasted engineering hours.
|
||||
- Be specific. "This might have issues" is useless. "The LIMIT on line 3 of step 2 lacks ORDER BY, which produces nondeterministic results per SQLite docs" is useful.
|
||||
- Calibrate severity honestly. Not everything is a must-fix. Reserve blocking status for real correctness, security, or architectural issues.
|
||||
- Respect the engineer's judgment. They know the codebase better than you. Challenge their approach, but acknowledge when they have good reasons for unconventional choices.
|
||||
- Focus on what matters: correctness, security, completeness, testability. Skip style nitpicks.
|
||||
- Think adversarially. What inputs break this? What happens under load? What if the network fails mid-operation?
|
||||
- Be fast. Engineers are waiting on your review to start coding. A good review in 5 minutes beats a perfect review in an hour.
|
||||
|
||||
## Voice and Tone
|
||||
|
||||
- Direct and technical. Lead with the finding, then explain why it matters.
|
||||
- Constructive, not combative. "This misses X" not "You forgot X."
|
||||
- Brief. A review should be scannable in under 2 minutes.
|
||||
- No filler. Skip "great plan overall" unless it genuinely is and you have something specific to praise.
|
||||
- When uncertain, say so. "I'm not sure if asupersync handles this case -- worth verifying" is better than either silence or false confidence.
|
||||
@@ -1,729 +0,0 @@
|
||||
# Spec: Discussion Analysis — LLM-Powered Discourse Enrichment
|
||||
|
||||
**Parent:** SPEC_explain.md (replaces key_decisions heuristic, line 270)
|
||||
**Created:** 2026-03-11
|
||||
**Status:** DRAFT — iterating with user
|
||||
|
||||
## Spec Status
|
||||
| Section | Status | Notes |
|
||||
|---------|--------|-------|
|
||||
| Objective | draft | Core vision defined, success metrics TBD |
|
||||
| Tech Stack | draft | Bedrock + Anthropic API dual-backend |
|
||||
| Architecture | draft | Pre-computed enrichment pipeline |
|
||||
| Schema | draft | `discussion_analysis` table with staleness detection |
|
||||
| CLI Command | draft | `lore enrich discussions` |
|
||||
| LLM Provider | draft | Configurable backend abstraction |
|
||||
| Explain Integration | draft | Replaces heuristic with DB lookup |
|
||||
| Prompt Design | draft | Thread-level discourse classification |
|
||||
| Testing Strategy | draft | Includes mock LLM for deterministic tests |
|
||||
| Boundaries | draft | |
|
||||
| Tasks | not started | Blocked on spec approval |
|
||||
|
||||
**Definition of Complete:** All sections `complete`, Open Questions empty,
|
||||
every user journey has tasks, every task has TDD workflow and acceptance criteria.
|
||||
|
||||
---
|
||||
|
||||
## Open Questions (Resolve Before Implementation)
|
||||
|
||||
1. **Bedrock model ID**: Which exact Bedrock model will be used? (Assuming `anthropic.claude-3-haiku-*` — need the org-approved ARN or model ID.)
|
||||
2. **Auth mechanism**: Does the Bedrock setup use IAM role assumption, SSO profile, or explicit access keys? This affects the SDK configuration.
|
||||
3. **Rate limiting**: What's the org's Bedrock rate limit? This determines batch concurrency.
|
||||
4. **Cost ceiling**: Should there be a per-run token budget or discussion count cap? (e.g., `--max-threads 200`)
|
||||
5. **Confidence thresholds**: Below what confidence should we discard an analysis vs. store it with low confidence?
|
||||
6. **explain integration field name**: Replace `key_decisions` entirely, or add a new `discourse_analysis` section alongside it? (Recommendation: replace `key_decisions` — the heuristic is acknowledged as inadequate.)
|
||||
|
||||
---
|
||||
|
||||
## Objective
|
||||
|
||||
**Goal:** Pre-compute structured discourse analysis for discussion threads using an LLM (Claude Haiku via Bedrock or Anthropic API), storing results locally so that `lore explain` and future commands can surface meaningful decisions, answered questions, and consensus without runtime LLM calls.
|
||||
|
||||
**Problem:** The current `key_decisions` heuristic in `explain` correlates state-change events with notes by the same actor within 60 minutes. This produces mostly empty results because real decisions happen in discussion threads, not at the moment of state changes. The heuristic cannot understand conversational semantics — whether a comment confirms a proposal, answers a question, or represents consensus.
|
||||
|
||||
**What this enables:**
|
||||
- `lore explain issues 42` shows *actual* decisions extracted from discussion threads, not event-note temporal coincidences
|
||||
- Reusable across commands — any command can query `discussion_analysis` for pre-computed insights
|
||||
- Fully offline at query time — LLM enrichment is a batch pre-computation step
|
||||
- Incremental — only re-analyzes threads whose notes have changed (staleness via `notes_hash`)
|
||||
|
||||
**Success metrics:**
|
||||
- `lore enrich discussions` processes 100 threads in <60s with Haiku
|
||||
- `lore explain` key_decisions section populated from enrichment data in <500ms (no LLM calls)
|
||||
- Staleness detection: re-running enrichment skips unchanged threads
|
||||
- Zero impact on users without LLM configuration — graceful degradation to empty key_decisions
|
||||
|
||||
---
|
||||
|
||||
## Tech Stack & Constraints
|
||||
|
||||
| Layer | Technology | Notes |
|
||||
|-------|-----------|-------|
|
||||
| Language | Rust | nightly-2026-03-01 |
|
||||
| LLM (primary) | Claude Haiku via AWS Bedrock | Org-approved, security-compliant |
|
||||
| LLM (fallback) | Claude Haiku via Anthropic API | For personal/non-org use |
|
||||
| HTTP | asupersync `HttpClient` | Existing wrapper in `src/http.rs` |
|
||||
| Database | SQLite via rusqlite | New migration for `discussion_analysis` table |
|
||||
| Config | `~/.config/lore/config.json` | New `enrichment` section |
|
||||
|
||||
**Constraints:**
|
||||
- Bedrock is the primary backend (org security requirement for Taylor's work context)
|
||||
- Anthropic API is an alternative for non-org users
|
||||
- `lore explain` must NEVER make runtime LLM calls — all enrichment is pre-computed
|
||||
- `lore explain` performance budget unchanged: <500ms
|
||||
- Enrichment is an explicit opt-in step (`lore enrich`), never runs during `sync`
|
||||
- Must work when no LLM is configured — `key_decisions` degrades to empty array (or falls back to heuristic as transitional behavior)
|
||||
|
||||
---
|
||||
|
||||
## Architecture
|
||||
|
||||
### System Overview
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────┐
|
||||
│ lore enrich │
|
||||
│ (explicit user/agent command, batch operation) │
|
||||
└──────────────────────┬──────────────────────────┘
|
||||
│
|
||||
┌─────────────▼─────────────┐
|
||||
│ Enrichment Pipeline │
|
||||
│ 1. Select stale threads │
|
||||
│ 2. Build LLM prompts │
|
||||
│ 3. Call LLM (batched) │
|
||||
│ 4. Parse responses │
|
||||
│ 5. Store in DB │
|
||||
└─────────────┬─────────────┘
|
||||
│
|
||||
┌─────────────▼─────────────┐
|
||||
│ discussion_analysis │
|
||||
│ (SQLite table) │
|
||||
└─────────────┬─────────────┘
|
||||
│
|
||||
┌─────────────▼─────────────┐
|
||||
│ lore explain / other │
|
||||
│ (simple SELECT query) │
|
||||
└───────────────────────────┘
|
||||
```
|
||||
|
||||
### Data Flow
|
||||
|
||||
1. **Staleness detection**: For each discussion, compute `SHA-256(sorted note IDs + note bodies)`. Compare against stored `notes_hash`. Skip if unchanged.
|
||||
2. **Prompt construction**: Extract the last N notes (configurable, default 5) from the thread. Build a structured prompt asking for discourse classification.
|
||||
3. **LLM call**: Send to configured backend (Bedrock or Anthropic API). Parse structured JSON response.
|
||||
4. **Storage**: Upsert into `discussion_analysis` with analysis results, model ID, timestamp, and notes_hash.
|
||||
|
||||
### Pre-computation vs Runtime Trade-offs
|
||||
|
||||
| Concern | Pre-computed (chosen) | Runtime |
|
||||
|---------|----------------------|---------|
|
||||
| explain latency | <500ms (DB query) | 2-5s per thread (LLM call) |
|
||||
| Offline capability | Full | None |
|
||||
| Bedrock compliance | Clean separation | Leaks into explain path |
|
||||
| Reusability | Any command can query | Tied to explain |
|
||||
| Freshness | Stale until re-enriched | Always current |
|
||||
| Cost | Batch (predictable) | Per-query (unbounded) |
|
||||
|
||||
---
|
||||
|
||||
## Schema
|
||||
|
||||
### New Migration (next available version)
|
||||
|
||||
```sql
|
||||
CREATE TABLE discussion_analysis (
|
||||
id INTEGER PRIMARY KEY,
|
||||
discussion_id INTEGER NOT NULL REFERENCES discussions(id),
|
||||
analysis_type TEXT NOT NULL, -- 'decision', 'question_answered', 'consensus', 'open_debate', 'informational'
|
||||
confidence REAL NOT NULL, -- 0.0 to 1.0
|
||||
summary TEXT NOT NULL, -- LLM-generated 1-2 sentence summary
|
||||
evidence_note_ids TEXT, -- JSON array of note IDs that support this analysis
|
||||
model_id TEXT NOT NULL, -- e.g. 'anthropic.claude-3-haiku-20240307-v1:0'
|
||||
analyzed_at INTEGER NOT NULL, -- ms epoch
|
||||
notes_hash TEXT NOT NULL, -- SHA-256 of thread content for staleness detection
|
||||
|
||||
UNIQUE(discussion_id, analysis_type)
|
||||
);
|
||||
|
||||
CREATE INDEX idx_discussion_analysis_discussion
|
||||
ON discussion_analysis(discussion_id);
|
||||
|
||||
CREATE INDEX idx_discussion_analysis_type
|
||||
ON discussion_analysis(analysis_type);
|
||||
```
|
||||
|
||||
**Design decisions:**
|
||||
- `UNIQUE(discussion_id, analysis_type)`: A thread can have at most one analysis per type. Re-enrichment upserts.
|
||||
- `evidence_note_ids` is a JSON array (not a junction table) because it's read-only metadata, never queried by note ID.
|
||||
- `notes_hash` enables O(1) staleness checks without re-reading all notes.
|
||||
- `confidence` allows filtering in queries (e.g., only show decisions with confidence > 0.7).
|
||||
- `analysis_type` uses lowercase snake_case strings, not an enum constraint, for forward compatibility.
|
||||
|
||||
### Analysis Types
|
||||
|
||||
| Type | Description | Example |
|
||||
|------|-------------|---------|
|
||||
| `decision` | A concrete decision was made or confirmed | "Team agreed to use Redis for caching" |
|
||||
| `question_answered` | A question was asked and definitively answered | "Confirmed: the API supports pagination via cursor" |
|
||||
| `consensus` | Multiple participants converged on an approach | "All reviewers approved the retry-with-backoff strategy" |
|
||||
| `open_debate` | Active disagreement or unresolved discussion | "Disagreement on whether to use gRPC vs REST" |
|
||||
| `informational` | Thread is purely informational, no actionable discourse | "Status update on deployment progress" |
|
||||
|
||||
### Notes Hash Computation
|
||||
|
||||
```
|
||||
notes_hash = SHA-256(
|
||||
note_1_id + ":" + note_1_body + "\n" +
|
||||
note_2_id + ":" + note_2_body + "\n" +
|
||||
...
|
||||
)
|
||||
```
|
||||
|
||||
Notes sorted by `id` (insertion order) before hashing. This means:
|
||||
- New note added → hash changes → re-enrich
|
||||
- Note edited (body changes) → hash changes → re-enrich
|
||||
- No changes → hash matches → skip
|
||||
|
||||
---
|
||||
|
||||
## CLI Command
|
||||
|
||||
### `lore enrich discussions`
|
||||
|
||||
```bash
|
||||
# Enrich all stale discussions across all projects
|
||||
lore enrich discussions
|
||||
|
||||
# Scope to a project
|
||||
lore enrich discussions -p group/repo
|
||||
|
||||
# Scope to a single entity's discussions
|
||||
lore enrich discussions --issue 42 -p group/repo
|
||||
lore enrich discussions --mr 99 -p group/repo
|
||||
|
||||
# Force re-enrichment (ignore staleness)
|
||||
lore enrich discussions --force
|
||||
|
||||
# Dry run (show what would be enriched, don't call LLM)
|
||||
lore enrich discussions --dry-run
|
||||
|
||||
# Limit batch size
|
||||
lore enrich discussions --max-threads 50
|
||||
|
||||
# Robot mode
|
||||
lore -J enrich discussions
|
||||
```
|
||||
|
||||
### Robot Mode Output
|
||||
|
||||
```json
|
||||
{
|
||||
"ok": true,
|
||||
"data": {
|
||||
"total_discussions": 1200,
|
||||
"stale": 45,
|
||||
"enriched": 45,
|
||||
"skipped_unchanged": 1155,
|
||||
"errors": 0,
|
||||
"tokens_used": {
|
||||
"input": 23400,
|
||||
"output": 4500
|
||||
}
|
||||
},
|
||||
"meta": { "elapsed_ms": 32000 }
|
||||
}
|
||||
```
|
||||
|
||||
### Human Mode Output
|
||||
|
||||
```
|
||||
Enriching discussions...
|
||||
|
||||
Project: vs/typescript-code
|
||||
Discussions: 1,200 total, 45 stale
|
||||
Enriching: ████████████████████ 45/45
|
||||
Results: 12 decisions, 8 questions answered, 5 consensus, 3 debates, 17 informational
|
||||
Tokens: 23.4K input, 4.5K output
|
||||
|
||||
Done in 32s
|
||||
```
|
||||
|
||||
### Command Registration
|
||||
|
||||
```rust
|
||||
/// Pre-compute discourse analysis for discussion threads using LLM
|
||||
#[command(after_help = "\x1b[1mExamples:\x1b[0m
|
||||
lore enrich discussions # Enrich all stale discussions
|
||||
lore enrich discussions -p group/repo # Scope to project
|
||||
lore enrich discussions --issue 42 # Single issue's discussions
|
||||
lore -J enrich discussions --dry-run # Preview what would be enriched")]
|
||||
Enrich {
|
||||
/// What to enrich: "discussions"
|
||||
#[arg(value_parser = ["discussions"])]
|
||||
target: String,
|
||||
|
||||
/// Scope to project (fuzzy match)
|
||||
#[arg(short, long)]
|
||||
project: Option<String>,
|
||||
|
||||
/// Scope to a specific issue's discussions
|
||||
#[arg(long, conflicts_with = "mr")]
|
||||
issue: Option<i64>,
|
||||
|
||||
/// Scope to a specific MR's discussions
|
||||
#[arg(long, conflicts_with = "issue")]
|
||||
mr: Option<i64>,
|
||||
|
||||
/// Re-enrich all threads regardless of staleness
|
||||
#[arg(long)]
|
||||
force: bool,
|
||||
|
||||
/// Show what would be enriched without calling LLM
|
||||
#[arg(long)]
|
||||
dry_run: bool,
|
||||
|
||||
/// Maximum threads to enrich in one run
|
||||
#[arg(long, default_value = "500")]
|
||||
max_threads: usize,
|
||||
},
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## LLM Provider Abstraction
|
||||
|
||||
### Config Schema
|
||||
|
||||
New `enrichment` section in `~/.config/lore/config.json`:
|
||||
|
||||
```json
|
||||
{
|
||||
"enrichment": {
|
||||
"provider": "bedrock",
|
||||
"bedrock": {
|
||||
"region": "us-east-1",
|
||||
"modelId": "anthropic.claude-3-haiku-20240307-v1:0",
|
||||
"profile": "default"
|
||||
},
|
||||
"anthropicApi": {
|
||||
"modelId": "claude-3-haiku-20240307"
|
||||
},
|
||||
"concurrency": 4,
|
||||
"maxNotesPerThread": 5,
|
||||
"minConfidence": 0.6
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Provider selection:**
|
||||
- `"bedrock"` — AWS Bedrock (uses AWS SDK credential chain: env vars → profile → IAM role)
|
||||
- `"anthropic"` — Anthropic API (uses `ANTHROPIC_API_KEY` env var)
|
||||
- `null` or absent — enrichment disabled, `lore enrich` exits with informative message
|
||||
|
||||
### Rust Abstraction
|
||||
|
||||
```rust
|
||||
/// Trait for LLM backends. Implementations handle auth, serialization, and API specifics.
|
||||
#[async_trait]
|
||||
pub trait LlmProvider: Send + Sync {
|
||||
/// Send a prompt and get a structured response.
|
||||
async fn complete(&self, prompt: &str, max_tokens: u32) -> Result<LlmResponse>;
|
||||
|
||||
/// Provider name for logging/storage (e.g., "bedrock", "anthropic")
|
||||
fn provider_name(&self) -> &str;
|
||||
|
||||
/// Model identifier for storage (e.g., "anthropic.claude-3-haiku-20240307-v1:0")
|
||||
fn model_id(&self) -> &str;
|
||||
}
|
||||
|
||||
pub struct LlmResponse {
|
||||
pub content: String,
|
||||
pub input_tokens: u32,
|
||||
pub output_tokens: u32,
|
||||
pub stop_reason: String,
|
||||
}
|
||||
```
|
||||
|
||||
### Bedrock Implementation Notes
|
||||
|
||||
- Uses AWS SDK `InvokeModel` API (not Converse) for Anthropic models on Bedrock
|
||||
- Request body follows Anthropic Messages API format, wrapped in Bedrock's envelope
|
||||
- Auth: AWS credential chain (env → profile → IMDS)
|
||||
- Region from config or `AWS_REGION` env var
|
||||
- Content type: `application/json`, accept: `application/json`
|
||||
|
||||
### Anthropic API Implementation Notes
|
||||
|
||||
- Standard Messages API (`POST /v1/messages`)
|
||||
- Auth: `x-api-key` header from `ANTHROPIC_API_KEY` env var
|
||||
- Model ID from config `enrichment.anthropicApi.modelId`
|
||||
|
||||
---
|
||||
|
||||
## Prompt Design
|
||||
|
||||
### Thread-Level Analysis Prompt
|
||||
|
||||
The prompt receives the last N notes from a discussion thread and classifies the discourse.
|
||||
|
||||
```
|
||||
You are analyzing a discussion thread from a software project's issue tracker.
|
||||
|
||||
Thread context:
|
||||
- Entity: {entity_type} #{iid} "{title}"
|
||||
- Thread started: {first_note_at}
|
||||
- Total notes in thread: {note_count}
|
||||
|
||||
Notes (most recent {N} shown):
|
||||
|
||||
[Note by @{author} at {timestamp}]
|
||||
{body}
|
||||
|
||||
[Note by @{author} at {timestamp}]
|
||||
{body}
|
||||
|
||||
...
|
||||
|
||||
Classify this thread's discourse. Respond with JSON only:
|
||||
|
||||
{
|
||||
"analysis_type": "decision" | "question_answered" | "consensus" | "open_debate" | "informational",
|
||||
"confidence": 0.0-1.0,
|
||||
"summary": "1-2 sentence summary of what was decided/answered/debated",
|
||||
"evidence_note_indices": [0, 2] // indices of notes that most support this classification
|
||||
}
|
||||
|
||||
Classification guide:
|
||||
- "decision": A concrete choice was made. Look for: "let's go with", "agreed", "approved", explicit confirmation of an approach.
|
||||
- "question_answered": A question was asked and definitively answered. Look for: question mark followed by a clear factual response.
|
||||
- "consensus": Multiple people converged. Look for: multiple approvals, "+1", "LGTM", agreement from different authors.
|
||||
- "open_debate": Active disagreement or unresolved alternatives. Look for: "but", "alternatively", "I disagree", competing proposals without resolution.
|
||||
- "informational": Status updates, FYI notes, no actionable discourse.
|
||||
|
||||
If the thread is ambiguous, prefer "informational" with lower confidence over guessing.
|
||||
```
|
||||
|
||||
### Prompt Design Principles
|
||||
|
||||
1. **Structured JSON output** — Haiku is reliable at JSON generation with clear schema
|
||||
2. **Evidence-backed** — `evidence_note_indices` ties the classification to specific notes, enabling the UI to show "why"
|
||||
3. **Conservative default** — "informational" is the fallback, preventing false-positive decisions
|
||||
4. **Limited context window** — Last 5 notes (configurable) keeps token usage low per thread
|
||||
5. **No system prompt tricks** — Straightforward classification task within Haiku's strengths
|
||||
|
||||
### Token Budget Estimation
|
||||
|
||||
| Component | Tokens (approx) |
|
||||
|-----------|-----------------|
|
||||
| System/instruction prompt | ~300 |
|
||||
| Thread metadata | ~50 |
|
||||
| 5 notes (avg 100 words each) | ~750 |
|
||||
| Response | ~100 |
|
||||
| **Total per thread** | **~1,200** |
|
||||
|
||||
At Haiku pricing (~$0.25/1M input, ~$1.25/1M output):
|
||||
- 100 threads ≈ $0.03 input + $0.01 output = **~$0.04**
|
||||
- 1,000 threads ≈ **~$0.40**
|
||||
|
||||
---
|
||||
|
||||
## Explain Integration
|
||||
|
||||
### Current Behavior (to be replaced)
|
||||
|
||||
`explain.rs:650` — `extract_key_decisions()` uses the 60-minute same-actor heuristic.
|
||||
|
||||
### New Behavior
|
||||
|
||||
When `discussion_analysis` table has data for the entity's discussions:
|
||||
|
||||
```rust
|
||||
fn fetch_key_decisions_from_enrichment(
|
||||
conn: &Connection,
|
||||
entity_type: &str,
|
||||
entity_id: i64,
|
||||
max_decisions: usize,
|
||||
) -> Result<Vec<KeyDecision>> {
|
||||
let id_col = id_column_for(entity_type);
|
||||
let sql = format!(
|
||||
"SELECT da.analysis_type, da.confidence, da.summary, da.evidence_note_ids,
|
||||
da.analyzed_at, d.gitlab_discussion_id
|
||||
FROM discussion_analysis da
|
||||
JOIN discussions d ON da.discussion_id = d.id
|
||||
WHERE d.{id_col} = ?1
|
||||
AND da.analysis_type IN ('decision', 'question_answered', 'consensus')
|
||||
AND da.confidence >= ?2
|
||||
ORDER BY da.confidence DESC, da.analyzed_at DESC
|
||||
LIMIT ?3"
|
||||
);
|
||||
// ... map to KeyDecision structs
|
||||
}
|
||||
```
|
||||
|
||||
### Fallback Strategy
|
||||
|
||||
```
|
||||
if discussion_analysis table has rows for this entity:
|
||||
use enrichment data → key_decisions
|
||||
else if enrichment is not configured:
|
||||
fall back to heuristic (existing behavior)
|
||||
else:
|
||||
return empty key_decisions with a hint: "Run 'lore enrich discussions' to populate"
|
||||
```
|
||||
|
||||
This preserves backwards compatibility during rollout. The heuristic can be removed entirely once enrichment is the established workflow.
|
||||
|
||||
### KeyDecision Struct Changes
|
||||
|
||||
```rust
|
||||
#[derive(Debug, Serialize)]
|
||||
pub struct KeyDecision {
|
||||
pub timestamp: String, // ISO 8601 (analyzed_at or note timestamp)
|
||||
pub actor: Option<String>, // May not be single-actor for consensus
|
||||
pub action: String, // analysis_type: "decision", "question_answered", "consensus"
|
||||
pub summary: String, // LLM-generated summary (replaces context_note)
|
||||
pub confidence: f64, // 0.0-1.0
|
||||
pub discussion_id: Option<String>, // gitlab_discussion_id for linking
|
||||
#[serde(skip_serializing_if = "Option::is_none")]
|
||||
pub source: Option<String>, // "enrichment" or "heuristic" (transitional)
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Testing Strategy
|
||||
|
||||
### Unit Tests (Mock LLM)
|
||||
|
||||
The LLM provider trait enables deterministic testing with a mock:
|
||||
|
||||
```rust
|
||||
struct MockLlmProvider {
|
||||
responses: Vec<String>, // pre-canned JSON responses
|
||||
call_count: AtomicUsize,
|
||||
}
|
||||
|
||||
impl LlmProvider for MockLlmProvider {
|
||||
async fn complete(&self, _prompt: &str, _max_tokens: u32) -> Result<LlmResponse> {
|
||||
let idx = self.call_count.fetch_add(1, Ordering::SeqCst);
|
||||
Ok(LlmResponse {
|
||||
content: self.responses[idx].clone(),
|
||||
input_tokens: 100,
|
||||
output_tokens: 50,
|
||||
stop_reason: "end_turn".to_string(),
|
||||
})
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Test Cases
|
||||
|
||||
| Test | What it validates |
|
||||
|------|-------------------|
|
||||
| `test_staleness_hash_changes_on_new_note` | notes_hash differs when note added |
|
||||
| `test_staleness_hash_stable_no_changes` | notes_hash identical on re-computation |
|
||||
| `test_enrichment_skips_unchanged_threads` | Threads with matching hash are not re-enriched |
|
||||
| `test_enrichment_force_ignores_hash` | `--force` re-enriches all threads |
|
||||
| `test_enrichment_stores_analysis` | Results persisted to `discussion_analysis` table |
|
||||
| `test_enrichment_upserts_on_rereun` | Re-enrichment updates existing rows |
|
||||
| `test_enrichment_dry_run_no_writes` | `--dry-run` produces count but writes nothing |
|
||||
| `test_enrichment_respects_max_threads` | Caps at `--max-threads` value |
|
||||
| `test_enrichment_scopes_to_project` | `-p` limits to project's discussions |
|
||||
| `test_enrichment_scopes_to_entity` | `--issue 42` limits to that issue's discussions |
|
||||
| `test_explain_uses_enrichment_data` | explain returns enrichment-sourced key_decisions |
|
||||
| `test_explain_falls_back_to_heuristic` | No enrichment data → heuristic results |
|
||||
| `test_explain_empty_when_no_data` | No enrichment, no heuristic matches → empty array |
|
||||
| `test_prompt_construction` | Prompt includes correct notes, metadata, and instruction |
|
||||
| `test_response_parsing_valid_json` | Well-formed LLM response parsed correctly |
|
||||
| `test_response_parsing_malformed` | Malformed response logged, thread skipped (not crash) |
|
||||
| `test_confidence_filter` | Only analysis above `minConfidence` shown in explain |
|
||||
| `test_provider_config_bedrock` | Bedrock config parsed and provider instantiated |
|
||||
| `test_provider_config_anthropic` | Anthropic API config parsed correctly |
|
||||
| `test_no_enrichment_config_graceful` | Missing enrichment config → informative message, exit 0 |
|
||||
|
||||
### Integration Tests
|
||||
|
||||
- **Real Bedrock call** (gated behind `#[ignore]` + env var `LORE_TEST_BEDROCK=1`): Sends one real prompt to Bedrock, asserts valid JSON response with expected schema.
|
||||
- **Full pipeline**: In-memory DB → insert discussions + notes → enrich with mock → verify `discussion_analysis` populated → run explain → verify key_decisions sourced from enrichment.
|
||||
|
||||
---
|
||||
|
||||
## Boundaries
|
||||
|
||||
### Always (autonomous)
|
||||
- Run `cargo test` and `cargo clippy` after every code change
|
||||
- Use `MockLlmProvider` in all non-integration tests
|
||||
- Respect `--dry-run` flag — never call LLM in dry-run mode
|
||||
- Log token usage for every enrichment run
|
||||
- Graceful degradation when no enrichment config exists
|
||||
|
||||
### Ask First (needs approval)
|
||||
- Adding AWS SDK or HTTP dependencies to Cargo.toml
|
||||
- Choosing between `aws-sdk-bedrockruntime` crate vs raw HTTP to Bedrock
|
||||
- Modifying the `Config` struct (new `enrichment` field)
|
||||
- Changing `KeyDecision` struct shape (affects robot mode API contract)
|
||||
|
||||
### Never (hard stops)
|
||||
- No LLM calls in `lore explain` path — enrichment is pre-computed only
|
||||
- No storing API keys in config file — use env vars / credential chain
|
||||
- No automatic enrichment during `lore sync` — enrichment is always explicit
|
||||
- No sending discussion content to any service other than the configured LLM provider
|
||||
|
||||
---
|
||||
|
||||
## Non-Goals
|
||||
|
||||
- **No real-time streaming** — Enrichment is batch, not streaming
|
||||
- **No multi-model ensemble** — Single model per run, configurable per config
|
||||
- **No custom fine-tuning** — Uses Haiku as-is with prompt engineering
|
||||
- **No enrichment of individual notes** — Thread-level only (the unit of discourse)
|
||||
- **No automatic re-enrichment on sync** — User/agent must explicitly run `lore enrich`
|
||||
- **No modification of discussion/notes tables** — Enrichment data lives in its own table
|
||||
- **No embedding-based approach** — This is classification, not similarity search
|
||||
|
||||
---
|
||||
|
||||
## User Journeys
|
||||
|
||||
### P1 — Critical
|
||||
- **UJ-1: Agent enriches discussions before explain**
|
||||
- Actor: AI agent (via robot mode)
|
||||
- Flow: `lore -J enrich discussions -p group/repo` → JSON summary of enrichment run → `lore -J explain issues 42` → key_decisions populated from enrichment
|
||||
- Error paths: No enrichment config (exit with suggestion), Bedrock auth failure (exit 5), rate limited (exit 7)
|
||||
- Implemented by: Tasks 1-5
|
||||
|
||||
### P2 — Important
|
||||
- **UJ-2: Human runs enrichment and checks results**
|
||||
- Actor: Developer at terminal
|
||||
- Flow: `lore enrich discussions` → progress bar → summary → `lore explain issues 42` → sees decisions in narrative
|
||||
- Error paths: Same as UJ-1 but with human-readable messages
|
||||
- Implemented by: Tasks 1-5
|
||||
|
||||
- **UJ-3: Incremental enrichment after sync**
|
||||
- Actor: AI agent or human
|
||||
- Flow: `lore sync` → new notes ingested → `lore enrich discussions` → only stale threads re-enriched → fast completion
|
||||
- Implemented by: Task 2 (staleness detection)
|
||||
|
||||
### P3 — Nice to Have
|
||||
- **UJ-4: Dry-run to estimate cost**
|
||||
- Actor: Cost-conscious user
|
||||
- Flow: `lore enrich discussions --dry-run` → see thread count and estimated tokens → decide whether to proceed
|
||||
- Implemented by: Task 4
|
||||
|
||||
---
|
||||
|
||||
## Tasks
|
||||
|
||||
### Phase 1: Schema & Provider Abstraction
|
||||
|
||||
- [ ] **Task 1:** Database migration + LLM provider trait
|
||||
- **Implements:** Infrastructure (all UJs)
|
||||
- **Files:** `src/core/db.rs` (migration), NEW `src/enrichment/mod.rs`, NEW `src/enrichment/provider.rs`
|
||||
- **Depends on:** Nothing
|
||||
- **Test-first:**
|
||||
1. Write `test_migration_creates_discussion_analysis_table`: run migrations, verify table exists with correct columns
|
||||
2. Write `test_provider_config_bedrock`: parse config JSON with bedrock enrichment section
|
||||
3. Write `test_provider_config_anthropic`: parse config JSON with anthropic enrichment section
|
||||
4. Write `test_no_enrichment_config_graceful`: parse config without enrichment section, verify `None`
|
||||
5. Run tests — all FAIL (red)
|
||||
6. Implement migration + `LlmProvider` trait + `EnrichmentConfig` struct + config parsing
|
||||
7. Run tests — all PASS (green)
|
||||
- **Acceptance:** Migration creates table. Config parses both provider variants. Missing config returns `None`.
|
||||
|
||||
### Phase 2: Staleness & Prompt Pipeline
|
||||
|
||||
- [ ] **Task 2:** Notes hash computation + staleness detection
|
||||
- **Implements:** UJ-3 (incremental enrichment)
|
||||
- **Files:** `src/enrichment/staleness.rs`
|
||||
- **Depends on:** Task 1
|
||||
- **Test-first:**
|
||||
1. Write `test_staleness_hash_changes_on_new_note`
|
||||
2. Write `test_staleness_hash_stable_no_changes`
|
||||
3. Write `test_enrichment_skips_unchanged_threads`
|
||||
4. Run tests — all FAIL (red)
|
||||
5. Implement `compute_notes_hash()` + `find_stale_discussions()` query
|
||||
6. Run tests — all PASS (green)
|
||||
- **Acceptance:** Hash deterministic. Stale detection correct. Unchanged threads skipped.
|
||||
|
||||
- [ ] **Task 3:** Prompt construction + response parsing
|
||||
- **Implements:** Core enrichment logic
|
||||
- **Files:** `src/enrichment/prompt.rs`, `src/enrichment/parser.rs`
|
||||
- **Depends on:** Task 1
|
||||
- **Test-first:**
|
||||
1. Write `test_prompt_construction`: verify prompt includes notes, metadata, instruction
|
||||
2. Write `test_response_parsing_valid_json`: well-formed response parsed
|
||||
3. Write `test_response_parsing_malformed`: malformed response returns error (not panic)
|
||||
4. Run tests — all FAIL (red)
|
||||
5. Implement `build_prompt()` + `parse_analysis_response()`
|
||||
6. Run tests — all PASS (green)
|
||||
- **Acceptance:** Prompt is well-formed. Parser handles valid and invalid responses gracefully.
|
||||
|
||||
### Phase 3: CLI Command & Pipeline
|
||||
|
||||
- [ ] **Task 4:** `lore enrich discussions` command + enrichment pipeline
|
||||
- **Implements:** UJ-1, UJ-2, UJ-4
|
||||
- **Files:** NEW `src/cli/commands/enrich.rs`, `src/cli/mod.rs`, `src/main.rs`
|
||||
- **Depends on:** Tasks 1, 2, 3
|
||||
- **Test-first:**
|
||||
1. Write `test_enrichment_stores_analysis`: mock LLM → verify rows in `discussion_analysis`
|
||||
2. Write `test_enrichment_upserts_on_rerun`: enrich → re-enrich → verify single row updated
|
||||
3. Write `test_enrichment_dry_run_no_writes`: dry-run → verify zero rows written
|
||||
4. Write `test_enrichment_respects_max_threads`: 10 stale, max=3 → only 3 enriched
|
||||
5. Write `test_enrichment_scopes_to_project`: verify project filter
|
||||
6. Write `test_enrichment_scopes_to_entity`: verify --issue/--mr filter
|
||||
7. Run tests — all FAIL (red)
|
||||
8. Implement: command registration, pipeline orchestration, mock-based tests
|
||||
9. Run tests — all PASS (green)
|
||||
- **Acceptance:** Full pipeline works with mock. Dry-run safe. Scoping correct. Robot JSON matches schema.
|
||||
|
||||
### Phase 4: LLM Backend Implementations
|
||||
|
||||
- [ ] **Task 5:** Bedrock + Anthropic API provider implementations
|
||||
- **Implements:** UJ-1, UJ-2 (actual LLM connectivity)
|
||||
- **Files:** `src/enrichment/bedrock.rs`, `src/enrichment/anthropic.rs`
|
||||
- **Depends on:** Task 4
|
||||
- **Test-first:**
|
||||
1. Write `test_bedrock_request_format`: verify request body matches Bedrock InvokeModel schema
|
||||
2. Write `test_anthropic_request_format`: verify request body matches Messages API schema
|
||||
3. Write integration test (gated `#[ignore]`): real Bedrock call, assert valid response
|
||||
4. Run tests — unit FAIL (red), integration skipped
|
||||
5. Implement both providers
|
||||
6. Run tests — all PASS (green)
|
||||
- **Acceptance:** Both providers construct valid requests. Auth works via standard credential chains. Integration test passes when enabled.
|
||||
|
||||
### Phase 5: Explain Integration
|
||||
|
||||
- [ ] **Task 6:** Replace heuristic with enrichment data in explain
|
||||
- **Implements:** UJ-1, UJ-2 (the payoff)
|
||||
- **Files:** `src/cli/commands/explain.rs`
|
||||
- **Depends on:** Task 4
|
||||
- **Test-first:**
|
||||
1. Write `test_explain_uses_enrichment_data`: insert mock enrichment rows → explain returns them as key_decisions
|
||||
2. Write `test_explain_falls_back_to_heuristic`: no enrichment rows → returns heuristic results
|
||||
3. Write `test_confidence_filter`: insert rows with varying confidence → only high-confidence shown
|
||||
4. Run tests — all FAIL (red)
|
||||
5. Implement `fetch_key_decisions_from_enrichment()` + fallback logic
|
||||
6. Run tests — all PASS (green)
|
||||
- **Acceptance:** Explain uses enrichment when available. Falls back gracefully. Confidence threshold respected.
|
||||
|
||||
---
|
||||
|
||||
## Dependencies (New Crates — Needs Discussion)
|
||||
|
||||
| Crate | Purpose | Alternative |
|
||||
|-------|---------|-------------|
|
||||
| `aws-sdk-bedrockruntime` | Bedrock InvokeModel API | Raw HTTP via existing `HttpClient` |
|
||||
| `sha2` | SHA-256 for notes_hash | Already in dependency tree? Check. |
|
||||
|
||||
**Decision needed:** Use AWS SDK crate (heavier but handles auth/signing) vs. raw HTTP with SigV4 signing (lighter but more implementation work)?
|
||||
|
||||
---
|
||||
|
||||
## Session Log
|
||||
|
||||
### Session 1 — 2026-03-11
|
||||
- Identified key_decisions heuristic as fundamentally inadequate (60-min same-actor window)
|
||||
- User vision: LLM-powered discourse analysis, pre-computed for offline explain
|
||||
- Key constraint: Bedrock required for org security compliance
|
||||
- Designed pre-computed enrichment architecture
|
||||
- Wrote initial spec draft for iteration
|
||||
@@ -1469,7 +1469,7 @@ async fn handle_search(
|
||||
if robot_mode {
|
||||
print_search_results_json(&response, elapsed_ms, args.fields.as_deref());
|
||||
} else {
|
||||
print_search_results(&response, explain);
|
||||
print_search_results(&response);
|
||||
}
|
||||
Ok(())
|
||||
}
|
||||
|
||||
@@ -946,7 +946,7 @@ fn mentioned_in_finds_mention_on_unassigned_issue() {
|
||||
);
|
||||
|
||||
let recency_cutoff = now_ms() - 7 * 24 * 3600 * 1000;
|
||||
let results = query_mentioned_in(&conn, "alice", &[], recency_cutoff, 0).unwrap();
|
||||
let results = query_mentioned_in(&conn, "alice", &[], recency_cutoff).unwrap();
|
||||
assert_eq!(results.len(), 1);
|
||||
assert_eq!(results[0].entity_type, "issue");
|
||||
assert_eq!(results[0].iid, 42);
|
||||
@@ -964,7 +964,7 @@ fn mentioned_in_excludes_assigned_issue() {
|
||||
insert_note_at(&conn, 200, disc_id, 1, "bob", false, "hey @alice", t);
|
||||
|
||||
let recency_cutoff = now_ms() - 7 * 24 * 3600 * 1000;
|
||||
let results = query_mentioned_in(&conn, "alice", &[], recency_cutoff, 0).unwrap();
|
||||
let results = query_mentioned_in(&conn, "alice", &[], recency_cutoff).unwrap();
|
||||
assert!(results.is_empty(), "should exclude assigned issues");
|
||||
}
|
||||
|
||||
@@ -979,7 +979,7 @@ fn mentioned_in_excludes_authored_issue() {
|
||||
insert_note_at(&conn, 200, disc_id, 1, "bob", false, "hey @alice", t);
|
||||
|
||||
let recency_cutoff = now_ms() - 7 * 24 * 3600 * 1000;
|
||||
let results = query_mentioned_in(&conn, "alice", &[], recency_cutoff, 0).unwrap();
|
||||
let results = query_mentioned_in(&conn, "alice", &[], recency_cutoff).unwrap();
|
||||
assert!(results.is_empty(), "should exclude authored issues");
|
||||
}
|
||||
|
||||
@@ -995,7 +995,7 @@ fn mentioned_in_finds_mention_on_non_authored_mr() {
|
||||
insert_note_at(&conn, 200, disc_id, 1, "bob", false, "cc @alice", t);
|
||||
|
||||
let recency_cutoff = now_ms() - 7 * 24 * 3600 * 1000;
|
||||
let results = query_mentioned_in(&conn, "alice", &[], recency_cutoff, 0).unwrap();
|
||||
let results = query_mentioned_in(&conn, "alice", &[], recency_cutoff).unwrap();
|
||||
assert_eq!(results.len(), 1);
|
||||
assert_eq!(results[0].entity_type, "mr");
|
||||
assert_eq!(results[0].iid, 99);
|
||||
@@ -1012,7 +1012,7 @@ fn mentioned_in_excludes_authored_mr() {
|
||||
insert_note_at(&conn, 200, disc_id, 1, "bob", false, "@alice thoughts?", t);
|
||||
|
||||
let recency_cutoff = now_ms() - 7 * 24 * 3600 * 1000;
|
||||
let results = query_mentioned_in(&conn, "alice", &[], recency_cutoff, 0).unwrap();
|
||||
let results = query_mentioned_in(&conn, "alice", &[], recency_cutoff).unwrap();
|
||||
assert!(results.is_empty(), "should exclude authored MRs");
|
||||
}
|
||||
|
||||
@@ -1028,7 +1028,7 @@ fn mentioned_in_excludes_reviewer_mr() {
|
||||
insert_note_at(&conn, 200, disc_id, 1, "charlie", false, "@alice fyi", t);
|
||||
|
||||
let recency_cutoff = now_ms() - 7 * 24 * 3600 * 1000;
|
||||
let results = query_mentioned_in(&conn, "alice", &[], recency_cutoff, 0).unwrap();
|
||||
let results = query_mentioned_in(&conn, "alice", &[], recency_cutoff).unwrap();
|
||||
assert!(
|
||||
results.is_empty(),
|
||||
"should exclude MRs where user is reviewer"
|
||||
@@ -1052,7 +1052,7 @@ fn mentioned_in_includes_recently_closed_issue() {
|
||||
insert_note_at(&conn, 200, disc_id, 1, "bob", false, "hey @alice", t);
|
||||
|
||||
let recency_cutoff = now_ms() - 7 * 24 * 3600 * 1000;
|
||||
let results = query_mentioned_in(&conn, "alice", &[], recency_cutoff, 0).unwrap();
|
||||
let results = query_mentioned_in(&conn, "alice", &[], recency_cutoff).unwrap();
|
||||
assert_eq!(results.len(), 1, "recently closed issue should be included");
|
||||
assert_eq!(results[0].state, "closed");
|
||||
}
|
||||
@@ -1074,7 +1074,7 @@ fn mentioned_in_excludes_old_closed_issue() {
|
||||
insert_note_at(&conn, 200, disc_id, 1, "bob", false, "hey @alice", t);
|
||||
|
||||
let recency_cutoff = now_ms() - 7 * 24 * 3600 * 1000;
|
||||
let results = query_mentioned_in(&conn, "alice", &[], recency_cutoff, 0).unwrap();
|
||||
let results = query_mentioned_in(&conn, "alice", &[], recency_cutoff).unwrap();
|
||||
assert!(results.is_empty(), "old closed issue should be excluded");
|
||||
}
|
||||
|
||||
@@ -1099,7 +1099,7 @@ fn mentioned_in_attention_needs_attention_when_unreplied() {
|
||||
// alice has NOT replied
|
||||
|
||||
let recency_cutoff = now_ms() - 7 * 24 * 3600 * 1000;
|
||||
let results = query_mentioned_in(&conn, "alice", &[], recency_cutoff, 0).unwrap();
|
||||
let results = query_mentioned_in(&conn, "alice", &[], recency_cutoff).unwrap();
|
||||
assert_eq!(results.len(), 1);
|
||||
assert_eq!(results[0].attention_state, AttentionState::NeedsAttention);
|
||||
}
|
||||
@@ -1126,7 +1126,7 @@ fn mentioned_in_attention_awaiting_when_replied() {
|
||||
insert_note_at(&conn, 201, disc_id, 1, "alice", false, "looks good", t2);
|
||||
|
||||
let recency_cutoff = now_ms() - 7 * 24 * 3600 * 1000;
|
||||
let results = query_mentioned_in(&conn, "alice", &[], recency_cutoff, 0).unwrap();
|
||||
let results = query_mentioned_in(&conn, "alice", &[], recency_cutoff).unwrap();
|
||||
assert_eq!(results.len(), 1);
|
||||
assert_eq!(results[0].attention_state, AttentionState::AwaitingResponse);
|
||||
}
|
||||
@@ -1147,7 +1147,7 @@ fn mentioned_in_project_filter() {
|
||||
insert_note_at(&conn, 201, disc_b, 2, "bob", false, "@alice", t);
|
||||
|
||||
let recency_cutoff = now_ms() - 7 * 24 * 3600 * 1000;
|
||||
let results = query_mentioned_in(&conn, "alice", &[1], recency_cutoff, 0).unwrap();
|
||||
let results = query_mentioned_in(&conn, "alice", &[1], recency_cutoff).unwrap();
|
||||
assert_eq!(results.len(), 1);
|
||||
assert_eq!(results[0].project_path, "group/repo-a");
|
||||
}
|
||||
@@ -1166,7 +1166,7 @@ fn mentioned_in_deduplicates_multiple_mentions_same_entity() {
|
||||
insert_note_at(&conn, 201, disc_id, 1, "charlie", false, "@alice +1", t2);
|
||||
|
||||
let recency_cutoff = now_ms() - 7 * 24 * 3600 * 1000;
|
||||
let results = query_mentioned_in(&conn, "alice", &[], recency_cutoff, 0).unwrap();
|
||||
let results = query_mentioned_in(&conn, "alice", &[], recency_cutoff).unwrap();
|
||||
assert_eq!(results.len(), 1, "should deduplicate to one entity");
|
||||
}
|
||||
|
||||
@@ -1190,47 +1190,10 @@ fn mentioned_in_rejects_false_positive_email() {
|
||||
);
|
||||
|
||||
let recency_cutoff = now_ms() - 7 * 24 * 3600 * 1000;
|
||||
let results = query_mentioned_in(&conn, "alice", &[], recency_cutoff, 0).unwrap();
|
||||
let results = query_mentioned_in(&conn, "alice", &[], recency_cutoff).unwrap();
|
||||
assert!(results.is_empty(), "email-like text should not match");
|
||||
}
|
||||
|
||||
#[test]
|
||||
fn mentioned_in_excludes_old_mention_on_open_issue() {
|
||||
let conn = setup_test_db();
|
||||
insert_project(&conn, 1, "group/repo");
|
||||
insert_issue(&conn, 10, 1, 42, "someone");
|
||||
let disc_id = 100;
|
||||
insert_discussion(&conn, disc_id, 1, None, Some(10));
|
||||
// Mention from 45 days ago — outside 30-day mention window
|
||||
let t = now_ms() - 45 * 24 * 3600 * 1000;
|
||||
insert_note_at(&conn, 200, disc_id, 1, "bob", false, "hey @alice", t);
|
||||
|
||||
let recency_cutoff = now_ms() - 7 * 24 * 3600 * 1000;
|
||||
let mention_cutoff = now_ms() - 30 * 24 * 3600 * 1000;
|
||||
let results = query_mentioned_in(&conn, "alice", &[], recency_cutoff, mention_cutoff).unwrap();
|
||||
assert!(
|
||||
results.is_empty(),
|
||||
"mentions older than 30 days should be excluded"
|
||||
);
|
||||
}
|
||||
|
||||
#[test]
|
||||
fn mentioned_in_includes_recent_mention_on_open_issue() {
|
||||
let conn = setup_test_db();
|
||||
insert_project(&conn, 1, "group/repo");
|
||||
insert_issue(&conn, 10, 1, 42, "someone");
|
||||
let disc_id = 100;
|
||||
insert_discussion(&conn, disc_id, 1, None, Some(10));
|
||||
// Mention from 5 days ago — within 30-day window
|
||||
let t = now_ms() - 5 * 24 * 3600 * 1000;
|
||||
insert_note_at(&conn, 200, disc_id, 1, "bob", false, "hey @alice", t);
|
||||
|
||||
let recency_cutoff = now_ms() - 7 * 24 * 3600 * 1000;
|
||||
let mention_cutoff = now_ms() - 30 * 24 * 3600 * 1000;
|
||||
let results = query_mentioned_in(&conn, "alice", &[], recency_cutoff, mention_cutoff).unwrap();
|
||||
assert_eq!(results.len(), 1, "recent mentions should be included");
|
||||
}
|
||||
|
||||
// ─── Helper Tests ──────────────────────────────────────────────────────────
|
||||
|
||||
#[test]
|
||||
|
||||
@@ -27,8 +27,6 @@ const DEFAULT_ACTIVITY_SINCE_DAYS: i64 = 1;
|
||||
const MS_PER_DAY: i64 = 24 * 60 * 60 * 1000;
|
||||
/// Recency window for closed/merged items in the "Mentioned In" section: 7 days.
|
||||
const RECENCY_WINDOW_MS: i64 = 7 * MS_PER_DAY;
|
||||
/// Only show mentions from notes created within this window (30 days).
|
||||
const MENTION_WINDOW_MS: i64 = 30 * MS_PER_DAY;
|
||||
|
||||
/// Resolve the effective username from CLI flag or config.
|
||||
///
|
||||
@@ -153,14 +151,7 @@ pub fn run_me(config: &Config, args: &MeArgs, robot_mode: bool) -> Result<()> {
|
||||
|
||||
let mentioned_in = if want_mentions {
|
||||
let recency_cutoff = crate::core::time::now_ms() - RECENCY_WINDOW_MS;
|
||||
let mention_cutoff = crate::core::time::now_ms() - MENTION_WINDOW_MS;
|
||||
query_mentioned_in(
|
||||
&conn,
|
||||
username,
|
||||
&project_ids,
|
||||
recency_cutoff,
|
||||
mention_cutoff,
|
||||
)?
|
||||
query_mentioned_in(&conn, username, &project_ids, recency_cutoff)?
|
||||
} else {
|
||||
Vec::new()
|
||||
};
|
||||
|
||||
@@ -849,7 +849,6 @@ fn build_mentioned_in_sql(project_clause: &str) -> String {
|
||||
LEFT JOIN note_ts_issue nt ON nt.issue_id = ci.id
|
||||
WHERE n.is_system = 0
|
||||
AND n.author_username != ?1
|
||||
AND n.created_at > ?3
|
||||
AND LOWER(n.body) LIKE '%@' || LOWER(?1) || '%'
|
||||
UNION ALL
|
||||
-- MR mentions (scoped to candidate entities only)
|
||||
@@ -863,7 +862,6 @@ fn build_mentioned_in_sql(project_clause: &str) -> String {
|
||||
LEFT JOIN note_ts_mr nt ON nt.merge_request_id = cm.id
|
||||
WHERE n.is_system = 0
|
||||
AND n.author_username != ?1
|
||||
AND n.created_at > ?3
|
||||
AND LOWER(n.body) LIKE '%@' || LOWER(?1) || '%'
|
||||
ORDER BY 6 DESC
|
||||
LIMIT 500",
|
||||
@@ -873,8 +871,7 @@ fn build_mentioned_in_sql(project_clause: &str) -> String {
|
||||
/// Query issues and MRs where the user is @mentioned but not assigned/authored/reviewing.
|
||||
///
|
||||
/// Includes open items unconditionally, plus recently-closed/merged items
|
||||
/// (where `updated_at > recency_cutoff_ms`). Only considers mentions in notes
|
||||
/// created after `mention_cutoff_ms` (typically 30 days ago).
|
||||
/// (where `updated_at > recency_cutoff_ms`).
|
||||
///
|
||||
/// Returns deduplicated results sorted by attention priority then recency.
|
||||
pub fn query_mentioned_in(
|
||||
@@ -882,16 +879,14 @@ pub fn query_mentioned_in(
|
||||
username: &str,
|
||||
project_ids: &[i64],
|
||||
recency_cutoff_ms: i64,
|
||||
mention_cutoff_ms: i64,
|
||||
) -> Result<Vec<MeMention>> {
|
||||
let project_clause = build_project_clause_at("p.id", project_ids, 4);
|
||||
let project_clause = build_project_clause_at("p.id", project_ids, 3);
|
||||
// Materialized CTEs avoid pathological query plans for project-scoped mentions.
|
||||
let sql = build_mentioned_in_sql(&project_clause);
|
||||
|
||||
let mut params: Vec<Box<dyn rusqlite::types::ToSql>> = Vec::new();
|
||||
params.push(Box::new(username.to_string()));
|
||||
params.push(Box::new(recency_cutoff_ms));
|
||||
params.push(Box::new(mention_cutoff_ms));
|
||||
for &pid in project_ids {
|
||||
params.push(Box::new(pid));
|
||||
}
|
||||
|
||||
@@ -479,107 +479,4 @@ mod tests {
|
||||
assert_eq!(value["data"]["cursor_reset"], serde_json::json!(true));
|
||||
assert_eq!(value["meta"]["elapsed_ms"], serde_json::json!(17));
|
||||
}
|
||||
|
||||
/// Integration test: full envelope serialization includes gitlab_base_url in meta.
|
||||
/// Guards against drift where the wiring from run_me -> print_me_json -> JSON
|
||||
/// could silently lose the base URL field.
|
||||
#[test]
|
||||
fn me_envelope_includes_gitlab_base_url_in_meta() {
|
||||
let dashboard = MeDashboard {
|
||||
username: "testuser".to_string(),
|
||||
since_ms: Some(1_700_000_000_000),
|
||||
summary: MeSummary {
|
||||
project_count: 1,
|
||||
open_issue_count: 0,
|
||||
authored_mr_count: 0,
|
||||
reviewing_mr_count: 0,
|
||||
mentioned_in_count: 0,
|
||||
needs_attention_count: 0,
|
||||
},
|
||||
open_issues: vec![],
|
||||
open_mrs_authored: vec![],
|
||||
reviewing_mrs: vec![],
|
||||
mentioned_in: vec![],
|
||||
activity: vec![],
|
||||
since_last_check: None,
|
||||
};
|
||||
|
||||
let envelope = MeJsonEnvelope {
|
||||
ok: true,
|
||||
data: MeDataJson::from_dashboard(&dashboard),
|
||||
meta: RobotMeta::with_base_url(42, "https://gitlab.example.com"),
|
||||
};
|
||||
|
||||
let value = serde_json::to_value(&envelope).unwrap();
|
||||
assert_eq!(value["ok"], serde_json::json!(true));
|
||||
assert_eq!(value["meta"]["elapsed_ms"], serde_json::json!(42));
|
||||
assert_eq!(
|
||||
value["meta"]["gitlab_base_url"],
|
||||
serde_json::json!("https://gitlab.example.com")
|
||||
);
|
||||
}
|
||||
|
||||
/// Verify activity events carry the fields needed for URL construction
|
||||
/// (entity_type, entity_iid, project) so consumers can combine with
|
||||
/// meta.gitlab_base_url to build links.
|
||||
#[test]
|
||||
fn activity_event_carries_url_construction_fields() {
|
||||
let dashboard = MeDashboard {
|
||||
username: "testuser".to_string(),
|
||||
since_ms: Some(1_700_000_000_000),
|
||||
summary: MeSummary {
|
||||
project_count: 1,
|
||||
open_issue_count: 0,
|
||||
authored_mr_count: 0,
|
||||
reviewing_mr_count: 0,
|
||||
mentioned_in_count: 0,
|
||||
needs_attention_count: 0,
|
||||
},
|
||||
open_issues: vec![],
|
||||
open_mrs_authored: vec![],
|
||||
reviewing_mrs: vec![],
|
||||
mentioned_in: vec![],
|
||||
activity: vec![MeActivityEvent {
|
||||
timestamp: 1_700_000_000_000,
|
||||
event_type: ActivityEventType::Note,
|
||||
entity_type: "mr".to_string(),
|
||||
entity_iid: 99,
|
||||
project_path: "group/repo".to_string(),
|
||||
actor: Some("alice".to_string()),
|
||||
is_own: false,
|
||||
summary: "Commented on MR".to_string(),
|
||||
body_preview: None,
|
||||
}],
|
||||
since_last_check: None,
|
||||
};
|
||||
|
||||
let envelope = MeJsonEnvelope {
|
||||
ok: true,
|
||||
data: MeDataJson::from_dashboard(&dashboard),
|
||||
meta: RobotMeta::with_base_url(0, "https://gitlab.example.com"),
|
||||
};
|
||||
|
||||
let value = serde_json::to_value(&envelope).unwrap();
|
||||
let event = &value["data"]["activity"][0];
|
||||
|
||||
// These three fields + meta.gitlab_base_url = complete URL
|
||||
assert_eq!(event["entity_type"], "mr");
|
||||
assert_eq!(event["entity_iid"], 99);
|
||||
assert_eq!(event["project"], "group/repo");
|
||||
|
||||
// Consumer constructs: https://gitlab.example.com/group/repo/-/merge_requests/99
|
||||
let base = value["meta"]["gitlab_base_url"].as_str().unwrap();
|
||||
let project = event["project"].as_str().unwrap();
|
||||
let entity_path = match event["entity_type"].as_str().unwrap() {
|
||||
"issue" => "issues",
|
||||
"mr" => "merge_requests",
|
||||
other => panic!("unexpected entity_type: {other}"),
|
||||
};
|
||||
let iid = event["entity_iid"].as_i64().unwrap();
|
||||
let url = format!("{base}/{project}/-/{entity_path}/{iid}");
|
||||
assert_eq!(
|
||||
url,
|
||||
"https://gitlab.example.com/group/repo/-/merge_requests/99"
|
||||
);
|
||||
}
|
||||
}
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
use std::collections::HashMap;
|
||||
|
||||
use crate::cli::render::{self, Theme};
|
||||
use crate::cli::render::Theme;
|
||||
use serde::Serialize;
|
||||
|
||||
use crate::Config;
|
||||
@@ -20,16 +20,11 @@ use crate::search::{
|
||||
pub struct SearchResultDisplay {
|
||||
pub document_id: i64,
|
||||
pub source_type: String,
|
||||
#[serde(skip_serializing_if = "Option::is_none")]
|
||||
pub source_entity_iid: Option<i64>,
|
||||
pub title: String,
|
||||
pub url: Option<String>,
|
||||
pub author: Option<String>,
|
||||
pub created_at: Option<String>,
|
||||
pub updated_at: Option<String>,
|
||||
/// Raw epoch ms for human rendering; not serialized to JSON.
|
||||
#[serde(skip)]
|
||||
pub updated_at_ms: Option<i64>,
|
||||
pub project_path: String,
|
||||
pub labels: Vec<String>,
|
||||
pub paths: Vec<String>,
|
||||
@@ -221,13 +216,11 @@ pub async fn run_search(
|
||||
results.push(SearchResultDisplay {
|
||||
document_id: row.document_id,
|
||||
source_type: row.source_type.clone(),
|
||||
source_entity_iid: row.source_entity_iid,
|
||||
title: row.title.clone().unwrap_or_default(),
|
||||
url: row.url.clone(),
|
||||
author: row.author.clone(),
|
||||
created_at: row.created_at.map(ms_to_iso),
|
||||
updated_at: row.updated_at.map(ms_to_iso),
|
||||
updated_at_ms: row.updated_at,
|
||||
project_path: row.project_path.clone(),
|
||||
labels: row.labels.clone(),
|
||||
paths: row.paths.clone(),
|
||||
@@ -249,7 +242,6 @@ pub async fn run_search(
|
||||
struct HydratedRow {
|
||||
document_id: i64,
|
||||
source_type: String,
|
||||
source_entity_iid: Option<i64>,
|
||||
title: Option<String>,
|
||||
url: Option<String>,
|
||||
author: Option<String>,
|
||||
@@ -276,26 +268,7 @@ fn hydrate_results(conn: &rusqlite::Connection, document_ids: &[i64]) -> Result<
|
||||
(SELECT json_group_array(dl.label_name)
|
||||
FROM document_labels dl WHERE dl.document_id = d.id) AS labels_json,
|
||||
(SELECT json_group_array(dp.path)
|
||||
FROM document_paths dp WHERE dp.document_id = d.id) AS paths_json,
|
||||
CASE d.source_type
|
||||
WHEN 'issue' THEN
|
||||
(SELECT i.iid FROM issues i WHERE i.id = d.source_id)
|
||||
WHEN 'merge_request' THEN
|
||||
(SELECT m.iid FROM merge_requests m WHERE m.id = d.source_id)
|
||||
WHEN 'discussion' THEN
|
||||
(SELECT COALESCE(
|
||||
(SELECT i.iid FROM issues i WHERE i.id = disc.issue_id),
|
||||
(SELECT m.iid FROM merge_requests m WHERE m.id = disc.merge_request_id)
|
||||
) FROM discussions disc WHERE disc.id = d.source_id)
|
||||
WHEN 'note' THEN
|
||||
(SELECT COALESCE(
|
||||
(SELECT i.iid FROM issues i WHERE i.id = disc.issue_id),
|
||||
(SELECT m.iid FROM merge_requests m WHERE m.id = disc.merge_request_id)
|
||||
) FROM notes n
|
||||
JOIN discussions disc ON disc.id = n.discussion_id
|
||||
WHERE n.id = d.source_id)
|
||||
ELSE NULL
|
||||
END AS source_entity_iid
|
||||
FROM document_paths dp WHERE dp.document_id = d.id) AS paths_json
|
||||
FROM json_each(?1) AS j
|
||||
JOIN documents d ON d.id = j.value
|
||||
JOIN projects p ON p.id = d.project_id
|
||||
@@ -320,7 +293,6 @@ fn hydrate_results(conn: &rusqlite::Connection, document_ids: &[i64]) -> Result<
|
||||
project_path: row.get(8)?,
|
||||
labels: parse_json_array(&labels_json),
|
||||
paths: parse_json_array(&paths_json),
|
||||
source_entity_iid: row.get(11)?,
|
||||
})
|
||||
})?
|
||||
.collect::<std::result::Result<Vec<_>, _>>()?;
|
||||
@@ -337,96 +309,6 @@ fn parse_json_array(json: &str) -> Vec<String> {
|
||||
.collect()
|
||||
}
|
||||
|
||||
/// Collapse newlines and runs of whitespace in a snippet into single spaces.
|
||||
///
|
||||
/// Document `content_text` includes multi-line metadata (Project:, URL:, Labels:, etc.).
|
||||
/// FTS5 snippet() preserves these newlines, causing unindented lines when rendered.
|
||||
fn collapse_newlines(s: &str) -> String {
|
||||
let mut result = String::with_capacity(s.len());
|
||||
let mut prev_was_space = false;
|
||||
for c in s.chars() {
|
||||
if c.is_ascii_whitespace() {
|
||||
if !prev_was_space {
|
||||
result.push(' ');
|
||||
prev_was_space = true;
|
||||
}
|
||||
} else {
|
||||
result.push(c);
|
||||
prev_was_space = false;
|
||||
}
|
||||
}
|
||||
result
|
||||
}
|
||||
|
||||
/// Truncate a snippet to `max_visible` visible characters, respecting `<mark>` tag boundaries.
|
||||
///
|
||||
/// Counts only visible text (not tags) toward the limit, and ensures we never cut
|
||||
/// inside a `<mark>...</mark>` pair (which would break `render_snippet` highlighting).
|
||||
fn truncate_snippet(snippet: &str, max_visible: usize) -> String {
|
||||
if max_visible < 4 {
|
||||
return snippet.to_string();
|
||||
}
|
||||
|
||||
let mut visible_count = 0;
|
||||
let mut result = String::new();
|
||||
let mut remaining = snippet;
|
||||
|
||||
while !remaining.is_empty() {
|
||||
if let Some(start) = remaining.find("<mark>") {
|
||||
// Count visible chars before the tag
|
||||
let before = &remaining[..start];
|
||||
let before_len = before.chars().count();
|
||||
if visible_count + before_len >= max_visible.saturating_sub(3) {
|
||||
// Truncate within the pre-tag text
|
||||
let take = max_visible.saturating_sub(3).saturating_sub(visible_count);
|
||||
let truncated: String = before.chars().take(take).collect();
|
||||
result.push_str(&truncated);
|
||||
result.push_str("...");
|
||||
return result;
|
||||
}
|
||||
result.push_str(before);
|
||||
visible_count += before_len;
|
||||
|
||||
// Find matching </mark>
|
||||
let after_open = &remaining[start + 6..];
|
||||
if let Some(end) = after_open.find("</mark>") {
|
||||
let highlighted = &after_open[..end];
|
||||
let hl_len = highlighted.chars().count();
|
||||
if visible_count + hl_len >= max_visible.saturating_sub(3) {
|
||||
// Truncate within the highlighted text
|
||||
let take = max_visible.saturating_sub(3).saturating_sub(visible_count);
|
||||
let truncated: String = highlighted.chars().take(take).collect();
|
||||
result.push_str("<mark>");
|
||||
result.push_str(&truncated);
|
||||
result.push_str("</mark>...");
|
||||
return result;
|
||||
}
|
||||
result.push_str(&remaining[start..start + 6 + end + 7]);
|
||||
visible_count += hl_len;
|
||||
remaining = &after_open[end + 7..];
|
||||
} else {
|
||||
// Unclosed <mark> — treat rest as plain text
|
||||
result.push_str(&remaining[start..]);
|
||||
break;
|
||||
}
|
||||
} else {
|
||||
// No more tags — handle remaining plain text
|
||||
let rest_len = remaining.chars().count();
|
||||
if visible_count + rest_len > max_visible && max_visible > 3 {
|
||||
let take = max_visible.saturating_sub(3).saturating_sub(visible_count);
|
||||
let truncated: String = remaining.chars().take(take).collect();
|
||||
result.push_str(&truncated);
|
||||
result.push_str("...");
|
||||
return result;
|
||||
}
|
||||
result.push_str(remaining);
|
||||
break;
|
||||
}
|
||||
}
|
||||
|
||||
result
|
||||
}
|
||||
|
||||
/// Render FTS snippet with `<mark>` tags as terminal highlight style.
|
||||
fn render_snippet(snippet: &str) -> String {
|
||||
let mut result = String::new();
|
||||
@@ -444,7 +326,7 @@ fn render_snippet(snippet: &str) -> String {
|
||||
result
|
||||
}
|
||||
|
||||
pub fn print_search_results(response: &SearchResponse, explain: bool) {
|
||||
pub fn print_search_results(response: &SearchResponse) {
|
||||
if !response.warnings.is_empty() {
|
||||
for w in &response.warnings {
|
||||
eprintln!("{} {}", Theme::warning().render("Warning:"), w);
|
||||
@@ -459,13 +341,11 @@ pub fn print_search_results(response: &SearchResponse, explain: bool) {
|
||||
return;
|
||||
}
|
||||
|
||||
// Phase 6: section divider header
|
||||
println!(
|
||||
"{}",
|
||||
render::section_divider(&format!(
|
||||
"{} results for '{}' {}",
|
||||
response.total_results, response.query, response.mode
|
||||
))
|
||||
"\n {} results for '{}' {}",
|
||||
Theme::bold().render(&response.total_results.to_string()),
|
||||
Theme::bold().render(&response.query),
|
||||
Theme::muted().render(&response.mode)
|
||||
);
|
||||
|
||||
for (i, result) in response.results.iter().enumerate() {
|
||||
@@ -479,75 +359,22 @@ pub fn print_search_results(response: &SearchResponse, explain: bool) {
|
||||
_ => Theme::muted().render(&format!("{:>5}", &result.source_type)),
|
||||
};
|
||||
|
||||
// Phase 1: entity ref (e.g. #42 or !99)
|
||||
let entity_ref = result
|
||||
.source_entity_iid
|
||||
.map(|iid| match result.source_type.as_str() {
|
||||
"issue" | "discussion" | "note" => Theme::issue_ref().render(&format!("#{iid}")),
|
||||
"merge_request" => Theme::mr_ref().render(&format!("!{iid}")),
|
||||
_ => String::new(),
|
||||
});
|
||||
// Title line: rank, type badge, title
|
||||
println!(
|
||||
" {:>3}. {} {}",
|
||||
Theme::muted().render(&(i + 1).to_string()),
|
||||
type_badge,
|
||||
Theme::bold().render(&result.title)
|
||||
);
|
||||
|
||||
// Phase 3: relative time
|
||||
let time_str = result
|
||||
.updated_at_ms
|
||||
.map(|ms| Theme::dim().render(&render::format_relative_time_compact(ms)));
|
||||
|
||||
// Phase 2: build prefix, compute indent from its visible width
|
||||
let prefix = format!(" {:>3}. {} ", i + 1, type_badge);
|
||||
let indent = " ".repeat(render::visible_width(&prefix));
|
||||
|
||||
// Title line: rank, type badge, entity ref, title, relative time
|
||||
let mut title_line = prefix;
|
||||
if let Some(ref eref) = entity_ref {
|
||||
title_line.push_str(eref);
|
||||
title_line.push_str(" ");
|
||||
}
|
||||
title_line.push_str(&Theme::bold().render(&result.title));
|
||||
if let Some(ref time) = time_str {
|
||||
title_line.push_str(" ");
|
||||
title_line.push_str(time);
|
||||
}
|
||||
println!("{title_line}");
|
||||
|
||||
// Metadata: project, author — compact middle-dot line
|
||||
// Metadata: project, author, labels — compact middle-dot line
|
||||
let sep = Theme::muted().render(" \u{b7} ");
|
||||
let mut meta_parts: Vec<String> = Vec::new();
|
||||
meta_parts.push(Theme::muted().render(&result.project_path));
|
||||
if let Some(ref author) = result.author {
|
||||
meta_parts.push(Theme::username().render(&format!("@{author}")));
|
||||
}
|
||||
println!("{indent}{}", meta_parts.join(&sep));
|
||||
|
||||
// Phase 5: limit snippet to ~2 terminal lines.
|
||||
// First collapse newlines — content_text includes multi-line metadata
|
||||
// (Project:, URL:, Labels:, etc.) that would print at column 0.
|
||||
let collapsed = collapse_newlines(&result.snippet);
|
||||
// Truncate based on visible text length (excluding <mark></mark> tags)
|
||||
// to avoid cutting inside a highlight tag pair.
|
||||
let max_snippet_width =
|
||||
render::terminal_width().saturating_sub(render::visible_width(&indent));
|
||||
let max_snippet_chars = max_snippet_width.saturating_mul(2);
|
||||
let snippet = truncate_snippet(&collapsed, max_snippet_chars);
|
||||
let rendered = render_snippet(&snippet);
|
||||
println!("{indent}{rendered}");
|
||||
|
||||
if let Some(ref explain_data) = result.explain {
|
||||
let mut explain_line = format!(
|
||||
"{indent}{} vec={} fts={} rrf={:.4}",
|
||||
Theme::accent().render("explain"),
|
||||
explain_data
|
||||
.vector_rank
|
||||
.map(|r| r.to_string())
|
||||
.unwrap_or_else(|| "-".into()),
|
||||
explain_data
|
||||
.fts_rank
|
||||
.map(|r| r.to_string())
|
||||
.unwrap_or_else(|| "-".into()),
|
||||
explain_data.rrf_score
|
||||
);
|
||||
// Phase 5: labels shown only in explain mode
|
||||
if explain && !result.labels.is_empty() {
|
||||
if !result.labels.is_empty() {
|
||||
let label_str = if result.labels.len() <= 3 {
|
||||
result.labels.join(", ")
|
||||
} else {
|
||||
@@ -557,26 +384,27 @@ pub fn print_search_results(response: &SearchResponse, explain: bool) {
|
||||
result.labels.len() - 2
|
||||
)
|
||||
};
|
||||
explain_line.push_str(&format!(" {}", Theme::muted().render(&label_str)));
|
||||
}
|
||||
println!("{explain_line}");
|
||||
}
|
||||
meta_parts.push(Theme::muted().render(&label_str));
|
||||
}
|
||||
println!(" {}", meta_parts.join(&sep));
|
||||
|
||||
// Phase 4: drill-down hint footer
|
||||
if let Some(first) = response.results.first()
|
||||
&& let Some(iid) = first.source_entity_iid
|
||||
{
|
||||
let cmd = match first.source_type.as_str() {
|
||||
"issue" | "discussion" | "note" => Some(format!("lore issues {iid}")),
|
||||
"merge_request" => Some(format!("lore mrs {iid}")),
|
||||
_ => None,
|
||||
};
|
||||
if let Some(cmd) = cmd {
|
||||
// Snippet with highlight styling
|
||||
let rendered = render_snippet(&result.snippet);
|
||||
println!(" {rendered}");
|
||||
|
||||
if let Some(ref explain) = result.explain {
|
||||
println!(
|
||||
"\n {} {}",
|
||||
Theme::dim().render("Tip:"),
|
||||
Theme::dim().render(&format!("{cmd} for details"))
|
||||
" {} vec={} fts={} rrf={:.4}",
|
||||
Theme::accent().render("explain"),
|
||||
explain
|
||||
.vector_rank
|
||||
.map(|r| r.to_string())
|
||||
.unwrap_or_else(|| "-".into()),
|
||||
explain
|
||||
.fts_rank
|
||||
.map(|r| r.to_string())
|
||||
.unwrap_or_else(|| "-".into()),
|
||||
explain.rrf_score
|
||||
);
|
||||
}
|
||||
}
|
||||
@@ -616,89 +444,3 @@ pub fn print_search_results_json(
|
||||
Err(e) => eprintln!("Error serializing to JSON: {e}"),
|
||||
}
|
||||
}
|
||||
|
||||
#[cfg(test)]
|
||||
mod tests {
|
||||
use super::*;
|
||||
|
||||
#[test]
|
||||
fn truncate_snippet_short_text_unchanged() {
|
||||
let s = "hello world";
|
||||
assert_eq!(truncate_snippet(s, 100), "hello world");
|
||||
}
|
||||
|
||||
#[test]
|
||||
fn truncate_snippet_plain_text_truncated() {
|
||||
let s = "this is a long string that exceeds the limit";
|
||||
let result = truncate_snippet(s, 20);
|
||||
assert!(result.ends_with("..."), "got: {result}");
|
||||
// Visible chars should be <= 20
|
||||
assert!(result.chars().count() <= 20, "got: {result}");
|
||||
}
|
||||
|
||||
#[test]
|
||||
fn truncate_snippet_preserves_mark_tags() {
|
||||
let s = "some text <mark>keyword</mark> and more text here that is long";
|
||||
let result = truncate_snippet(s, 30);
|
||||
// Should not cut inside a <mark> pair
|
||||
let open_count = result.matches("<mark>").count();
|
||||
let close_count = result.matches("</mark>").count();
|
||||
assert_eq!(open_count, close_count, "unbalanced tags in: {result}");
|
||||
}
|
||||
|
||||
#[test]
|
||||
fn truncate_snippet_cuts_before_mark_tag() {
|
||||
let s = "a]very long prefix that exceeds the limit <mark>word</mark>";
|
||||
let result = truncate_snippet(s, 15);
|
||||
assert!(result.ends_with("..."), "got: {result}");
|
||||
// The <mark> tag should not appear since we truncated before reaching it
|
||||
assert!(
|
||||
!result.contains("<mark>"),
|
||||
"should not include tag: {result}"
|
||||
);
|
||||
}
|
||||
|
||||
#[test]
|
||||
fn truncate_snippet_does_not_count_tags_as_visible() {
|
||||
// With tags, raw length is 42 chars. Without tags, visible is 29.
|
||||
let s = "prefix <mark>keyword</mark> suffix text";
|
||||
// If max_visible = 35, the visible text (29 chars) fits — should NOT truncate
|
||||
let result = truncate_snippet(s, 35);
|
||||
assert_eq!(result, s, "should not truncate when visible text fits");
|
||||
}
|
||||
|
||||
#[test]
|
||||
fn truncate_snippet_small_limit_returns_as_is() {
|
||||
let s = "text <mark>x</mark>";
|
||||
// Very small limit should return as-is (guard clause)
|
||||
assert_eq!(truncate_snippet(s, 3), s);
|
||||
}
|
||||
|
||||
#[test]
|
||||
fn collapse_newlines_flattens_multiline_metadata() {
|
||||
let s = "[[Issue]] #4018: Remove math.js\nProject: vs/typescript-code\nURL: https://example.com\nLabels: []";
|
||||
let result = collapse_newlines(s);
|
||||
assert!(
|
||||
!result.contains('\n'),
|
||||
"should not contain newlines: {result}"
|
||||
);
|
||||
assert_eq!(
|
||||
result,
|
||||
"[[Issue]] #4018: Remove math.js Project: vs/typescript-code URL: https://example.com Labels: []"
|
||||
);
|
||||
}
|
||||
|
||||
#[test]
|
||||
fn collapse_newlines_preserves_mark_tags() {
|
||||
let s = "first line\n<mark>keyword</mark>\nsecond line";
|
||||
let result = collapse_newlines(s);
|
||||
assert_eq!(result, "first line <mark>keyword</mark> second line");
|
||||
}
|
||||
|
||||
#[test]
|
||||
fn collapse_newlines_collapses_runs_of_whitespace() {
|
||||
let s = "a \n\n b\t\tc";
|
||||
let result = collapse_newlines(s);
|
||||
assert_eq!(result, "a b c");
|
||||
}
|
||||
}
|
||||
|
||||
@@ -569,32 +569,6 @@ pub fn terminal_width() -> usize {
|
||||
80
|
||||
}
|
||||
|
||||
/// Strip ANSI escape codes (SGR sequences) from a string.
|
||||
pub fn strip_ansi(s: &str) -> String {
|
||||
let mut out = String::with_capacity(s.len());
|
||||
let mut chars = s.chars();
|
||||
while let Some(c) = chars.next() {
|
||||
if c == '\x1b' {
|
||||
// Consume `[`, then digits/semicolons, then the final letter
|
||||
if chars.next() == Some('[') {
|
||||
for c in chars.by_ref() {
|
||||
if c.is_ascii_alphabetic() {
|
||||
break;
|
||||
}
|
||||
}
|
||||
}
|
||||
} else {
|
||||
out.push(c);
|
||||
}
|
||||
}
|
||||
out
|
||||
}
|
||||
|
||||
/// Compute the visible width of a string that may contain ANSI escape sequences.
|
||||
pub fn visible_width(s: &str) -> usize {
|
||||
strip_ansi(s).chars().count()
|
||||
}
|
||||
|
||||
/// Truncate a string to `max` characters, appending "..." if truncated.
|
||||
pub fn truncate(s: &str, max: usize) -> String {
|
||||
if max < 4 {
|
||||
@@ -1485,19 +1459,24 @@ mod tests {
|
||||
|
||||
// ── helpers ──
|
||||
|
||||
/// Delegate to the public `strip_ansi` for test assertions.
|
||||
/// Strip ANSI escape codes (SGR sequences) for content assertions.
|
||||
fn strip_ansi(s: &str) -> String {
|
||||
super::strip_ansi(s)
|
||||
}
|
||||
|
||||
#[test]
|
||||
fn visible_width_strips_ansi() {
|
||||
let styled = "\x1b[1mhello\x1b[0m".to_string();
|
||||
assert_eq!(super::visible_width(&styled), 5);
|
||||
}
|
||||
|
||||
#[test]
|
||||
fn visible_width_plain_string() {
|
||||
assert_eq!(super::visible_width("hello"), 5);
|
||||
let mut out = String::with_capacity(s.len());
|
||||
let mut chars = s.chars();
|
||||
while let Some(c) = chars.next() {
|
||||
if c == '\x1b' {
|
||||
// Consume `[`, then digits/semicolons, then the final letter
|
||||
if chars.next() == Some('[') {
|
||||
for c in chars.by_ref() {
|
||||
if c.is_ascii_alphabetic() {
|
||||
break;
|
||||
}
|
||||
}
|
||||
}
|
||||
} else {
|
||||
out.push(c);
|
||||
}
|
||||
}
|
||||
out
|
||||
}
|
||||
}
|
||||
|
||||
@@ -56,13 +56,7 @@ pub fn expand_fields_preset(fields: &[String], entity: &str) -> Vec<String> {
|
||||
.iter()
|
||||
.map(|s| (*s).to_string())
|
||||
.collect(),
|
||||
"search" => [
|
||||
"document_id",
|
||||
"title",
|
||||
"source_type",
|
||||
"source_entity_iid",
|
||||
"score",
|
||||
]
|
||||
"search" => ["document_id", "title", "source_type", "score"]
|
||||
.iter()
|
||||
.map(|s| (*s).to_string())
|
||||
.collect(),
|
||||
|
||||
@@ -154,25 +154,3 @@ fn test_percent_not_wildcard() {
|
||||
let id = resolve_project(&conn, "a%b").unwrap();
|
||||
assert_eq!(id, 1);
|
||||
}
|
||||
|
||||
#[test]
|
||||
fn test_lookup_by_gitlab_project_id() {
|
||||
use crate::test_support::{insert_project as insert_proj, setup_test_db};
|
||||
|
||||
let conn = setup_test_db();
|
||||
insert_proj(&conn, 1, "team/alpha");
|
||||
insert_proj(&conn, 2, "team/beta");
|
||||
|
||||
// insert_project sets gitlab_project_id = id * 100
|
||||
let path: String = conn
|
||||
.query_row(
|
||||
"SELECT path_with_namespace FROM projects
|
||||
WHERE gitlab_project_id = ?1
|
||||
ORDER BY id LIMIT 1",
|
||||
rusqlite::params![200_i64],
|
||||
|row| row.get(0),
|
||||
)
|
||||
.unwrap();
|
||||
|
||||
assert_eq!(path, "team/beta");
|
||||
}
|
||||
|
||||
Reference in New Issue
Block a user