# Link Two Entries Through Bundled CLI

## Test Type

- forward skill execution

## Purpose

- validate that a single agent can use `skills/repo-memory/` to add two durable
  knowledge entries, create a relation between them through the bundled CLI,
  and leave a durable graph edge in the SQLite database

## Preconditions

- `skills/repo-memory/assets/repo-memory` exists and is executable
- the test runner can create a temporary Git repository fixture
- the test runner can create a temporary SQLite DB path
- the repository fixture includes any evidence files needed for the two entries

## Inputs

- `SKILL_PATH=/.../skills/repo-memory`
- `TMPDIR=/tmp/...`
- `DB_PATH=TMPDIR/repo-memory.db`
- `REPO_PATH=TMPDIR/repo-fixture`

## Execution Parameters

- one agent only
- per-agent timeout: `3m`
- overall timeout: `4m`

## Execution Steps

1. Create a temporary Git repository fixture under `REPO_PATH`.
2. Add any files needed to justify two durable knowledge entries.
3. Ask the agent to use `$repo-memory` against `DB_PATH`.
4. Have the agent add one `term` entry and one `chain` entry for the same repo.
5. Have the agent link the first entry to the second with relation
   `related_to`.
6. Capture the agent summary and the concrete entry ids it reports.

## Validation Commands

Run these from the main thread after the agent stops:

```bash
SKILL_PATH/assets/repo-memory list --db DB_PATH --repo REPO_PATH
SKILL_PATH/assets/repo-memory events --db DB_PATH --id 1
SKILL_PATH/assets/repo-memory events --db DB_PATH --id 2
sqlite3 DB_PATH "SELECT relation FROM knowledge_links WHERE from_entry_id = 1 AND to_entry_id = 2;"
```

## Expected Outcomes

- both `add` calls succeed and leave two queryable entries
- `link` succeeds and reports the relation textually
- the final SQL validation returns one `related_to` row

## Assertions

- the agent used the bundled CLI for entry creation and relation creation
- the relation is durable in the packaged SQLite DB, not just mentioned in the summary
- both entries remain independently inspectable through `events`

## Cleanup

- keep the temporary DB and repo on failure
- remove temporary artifacts on success only if replay evidence is not needed