mirror of https://github.com/rennf93/roboco.git synced 2026-08-03 07:23:24 +02:00

Files

T

4fb0059556 fix: journals/learnings never reached the RAG corpus + git-readonly slug 404s (#339 )

* fix(rag): per-index chunk floors — journals and learnings were never indexed

The global 200-char garbage floor (sized for code/doc chunks) discarded
every templated journal note and most distilled org-memory lessons,
silently: ingest returned success with zero chunks, so agent journals
and learnings were never retrievable via RAG. IndexConfig now carries a
per-type min_chunk_length (journals 40, learnings 80, others unchanged).

* fix(mcp): git-readonly tools default project_slug from the container env

Agents 404ed /api/git/status with 'Project not found: roboco' — the
tools made the LLM supply the slug and six doc examples taught a slug
that matches no registered project. The tools now fall back to the
ROBOCO_PROJECT_SLUG the orchestrator already injects, and the stale
examples are corrected.

* feat(rag): startup backfill re-ingests zero-chunk journals and learnings

Before the per-index chunk-floor fix, ingest() returned success with
chunk_count=0 for undersized content: every historical journal entry and
distilled learning below the (then-global) 200-char floor was durably
recorded in journal_entries but silently never got a chunks_journals /
chunks_learnings row, and no exception meant the existing dead-letter
(rag_index_failures) never saw it either.

Extends the startup reconcile (roboco/api/app.py _reconcile_rag_indexes)
with a new pass: backfill_unindexed_journals (roboco/services/
rag_index_failures.py) queries journal_entries for rows missing from each
vector table and re-ingests them through the same live code paths
(_reindex_journal_entry / record_learning).

Journals and learnings are backfilled independently since a LEARNING entry
can clear the (lower) JOURNALS floor while still failing the (higher)
LEARNINGS floor — a learning's doc_source is a content hash, not the entry
id, so presence there is checked by hashing each candidate the same way
LearningsIndexPlugin.record_learning does and batch-querying chunks_learnings
for those exact sources.

Bounded to 200 rows per pass per boot (converges over restarts on a larger
backlog) and best-effort per row (one failure never aborts the pass). Rows
still under the current floor are excluded by a length filter in the SELECT
so they are never retried forever, and private entries are excluded from
the JOURNALS pass exactly like the live indexing path.

* test(rag): scope backfill assertions to their own rows

---------

Co-authored-by: Renn F <rennf93@users.noreply.github.com>

2026-07-08 16:03:00 +02:00

2.8 KiB

Raw Blame History

Git Tools

There is no "roboco_git_commit / _push / _create_pr / _merge_pr / _checkout" MCP tool. Anything mutating the repo goes through one of two role-scoped verbs and the choreographer handles git for you.

Read Operations (any role) — `roboco-git-readonly`

Tool	Purpose
`roboco_git_status`	View working tree status
`roboco_git_log`	View commit history
`roboco_git_branch_list`	List branches
`roboco_git_diff`	View changes

# project_slug is optional — omit it and your own project is used
# (from this agent's environment). Pass it explicitly only to inspect
# a different project than the one you're assigned to.
status = roboco_git_status()
diff = roboco_git_diff()
log = roboco_git_log(branch="feature/backend/a1b2c3d4")
branches = roboco_git_branch_list()

Branch Lifecycle — automatic

Branches are auto-created when an agent transitions a task to in_progress:

Root task → feature/team/ROOT_ID
Subtask → feature/team/ROOT_ID--SUB_ID
Sub-subtask → feature/team/ROOT_ID--SUB_ID--SUBSUB_ID

You never run git checkout or git branch yourself; calling i_will_work_on(task_id) (developers) or i_will_plan(task_id, plan) (PMs) creates the branch and switches your workspace to it.

Write Path — by role

Developers and Documenters → `commit` (roboco-do)

# Commit on your active task's branch. The choreographer:
#  - prefixes the message with [task-id]
#  - validates against commit_validator
#  - pushes to the remote branch
#  - opens a PR when the task transitions out of in_progress
commit(message="Add rate limiting endpoint", files=["roboco/api/routes/rate.py"])

There is no separate push step and no separate create_pr step. Both are side-effects of the lifecycle transitions the verbs already drive.

PMs → `complete` (roboco-flow)

# Cell PM completing a leaf task: merges the leaf PR.
# (Assembled cell→root / root→master PRs are opened by submit_up / submit_root
#  and gated in awaiting_pr_review first.) After a code root's gate clears,
# the Main PM's complete escalates to the CEO — the CEO merges root→master.
complete(task_id="a1b2c3d4-...", notes="QA passed; docs complete; ready to ship.")

PMs never run git directly and have no commit/push tools. PMs delegate code work to devs, then complete to merge once QA + docs sign off.

Branch Naming Convention

{type}/{team}/{task-hierarchy}

Type	Use
`feature/`	New functionality
`bug/`	Bug fixes
`chore/`	Maintenance
`docs/`	Documentation
`hotfix/`	Urgent fixes

Hierarchy uses -- (two hyphens) as the separator, not /, so a hierarchy slug like ABC12345--DEF67890--GHI11111 is one git branch segment, not three nested directories.

2.8 KiB Raw Blame History