ReRAG-ReBAC Development Assistant

Expert assistant for developing a secure Retrieval-Augmented Generation (RAG) system with Relationship-Based Access Control (ReBAC) using Ory Keto, SQLite vector search, and LLM integration.

System Overview

This skill helps develop and maintain an enterprise-grade document management system combining:

Project Context

**Module:** `rerag-rbac-rag-llm`

**Package Structure:** All internal packages under `/internal/`

**External Services:**

Key Components

Architecture

Vector Search Architecture

- Starts with topK × 2 candidates

- Doubles pool size each attempt (max 10 attempts)

- Returns best-effort results for sparse permission scenarios

Permission Model (ReBAC)

Three test users:

Instructions

When working on this codebase:

1. Code Standards

2. Testing Requirements

3. Common Development Commands

```bash

make test # Run all tests before committing

make lint # Check code quality

make format # Auto-format code

make dev # Start Keto and app in tmux

make setup # Setup permissions and load sample docs

make demo # Run interactive permission-aware demo

make reset # Full reset (clean + remove data)

make quick-start # One-liner: install + dev + demo

```

4. Adding New Features

**Step 1:** Design following existing patterns

**Step 2:** Implement with proper structure

**Step 3:** Create comprehensive tests

```go

func TestNewFeature(t *testing.T) {

server, embedder, vectorStore, llmClient, permService := createTestServer()

// Setup mocks

embedder.SetEmbedding("query", []float32{0.1, 0.2, 0.3})

// Test alice (limited access)

req := createAuthenticatedRequest(method, path, body, "alice")

w := httptest.NewRecorder()

server.handler(w, req)

assert.Equal(t, expectedStatus, w.Code)

// Test bob (different limited access)

// Test peter (admin access)

// Test error cases

}

```

**Step 4:** Update documentation

5. API Endpoints Reference

6. Working with Vector Search

When modifying storage layer:

7. Permission Testing Pattern

Always test with different user contexts:

```go

// Limited access - only John Doe docs

testUser := "alice"

// Limited access - only ABC Corp docs

testUser := "bob"

// Full admin access

testUser := "peter"

```

8. Important Constraints

- nomic-embed-text (embeddings)

- llama3.2:1b (LLM, temperature=0 for deterministic output)

9. Troubleshooting Common Issues

| Issue | Solution |

|-------|----------|

| Ollama connection refused | `docker start rerag-ollama` |

| Keto permission denied | `make start-keto` |

| Tests failing | `make deps` to update dependencies |

| Embedding errors | `docker exec rerag-ollama ollama pull nomic-embed-text` |

| LLM errors | `docker exec rerag-ollama ollama pull llama3.2:1b` |

10. Before Committing

1. Run `make test` - all tests must pass

2. Run `make lint` - fix any issues

3. Run `make format` - auto-format code

4. Verify permission scenarios work correctly

5. Update documentation if needed

11. CI/CD Notes

GitHub Actions uses:

Key Files Reference

```

/internal/api/

server.go # Main API implementation

server_test.go # Unit tests (655 lines - reference pattern)

e2e_test.go # End-to-end tests (503 lines)

query_test.go # Query scenarios (309 lines)

/internal/permissions/

keto.go # Ory Keto client

service.go # Permission service interface

/internal/storage/

sqlite_vector_store.go # SQLite vector store + adaptive search

vector_store.go # Storage interface

recursive_search_test.go # Adaptive search tests

/keto/

config.yml # Keto server config

definitions.opl # Permission model

```

Usage Examples

**Example 1: Adding a new authenticated endpoint**

```

Add a DELETE /documents/{id} endpoint that:

1. Requires authentication

2. Checks if user has delete permission via Keto

3. Removes document from vector store

4. Returns 204 No Content on success

5. Includes comprehensive tests for alice, bob, and peter

```

**Example 2: Refactoring storage layer**

```

Refactor the vector search to improve performance for large document sets while maintaining the existing interface. Ensure:

1. Adaptive recursive search behavior is preserved

2. Permission filtering works correctly

3. All existing tests pass

4. Add performance benchmarks

```

**Example 3: Adding comprehensive tests**

```

Create comprehensive tests for the /query endpoint following server_test.go patterns. Include:

1. Unit tests with mocked embedder, LLM, and permission service

2. Permission scenarios for alice, bob, and peter

3. Error cases (invalid query, no permissions, LLM failure)

4. Table-driven tests for different query types

```

Resources