Now I have the full picture. Here's my review:

---

## Code Review: `--github-repo` config for cross-platform PR lookups

### ftl_project_expert/cli.py:init
VERDICT: PASS
CORRECTNESS: VALID
SPEC_COMPLIANCE: N/A
ISSUE_COMPLIANCE: N/A
BELIEF_COMPLIANCE: N/A
TEST_COVERAGE: UNTESTED
INTEGRATION: WIRED
REASONING: The `--github-repo` option is cleanly added to `init`. It's stored in config unconditionally when provided, which means it works for all platforms (github, gitlab, jira). For a github platform project this is redundant with `repo` but harmless — and the `research` command guards against this with `config["platform"] != "github"`.

---

### ftl_project_expert/cli.py:_fetch_artifacts
VERDICT: CONCERN
CORRECTNESS: QUESTIONABLE
SPEC_COMPLIANCE: N/A
ISSUE_COMPLIANCE: N/A
BELIEF_COMPLIANCE: N/A
TEST_COVERAGE: UNTESTED
INTEGRATION: WIRED
REASONING: The fallback logic is correct for the PR case — it tries `source.get_pr()` first, then `github_source.get_pr()`, then emits a user-friendly skip message. However, there's an asymmetry: for `ref["type"] == "issue"`, the code calls `source.get_issue(ref["number"])` which will fail on Jira (Jira uses string keys, not integer numbers — see `get_issue(self, key: str)` in jira.py:128). This is a pre-existing bug not introduced by this PR, but the new `github_source` fallback pattern could have been extended to issues too — a Jira project with `--github-repo` might reference `#42` which would try `jira_source.get_issue(42)` and likely error. The exception handler catches this, so it's not a crash, but it's a missed opportunity. Additionally, `GitLabSource` has no `get_pr` method (confirmed by grep), so the `hasattr(source, "get_pr")` check is doing real work for GitLab — the fallback to `github_source` will fire correctly for GitLab+github_repo configs.

---

### ftl_project_expert/cli.py:research
VERDICT: PASS
CORRECTNESS: VALID
SPEC_COMPLIANCE: N/A
ISSUE_COMPLIANCE: N/A
BELIEF_COMPLIANCE: N/A
TEST_COVERAGE: UNTESTED
INTEGRATION: WIRED
REASONING: The `github_source` is constructed once at the top of `research()` and threaded into `_research_one` via closure, which passes it to `_fetch_artifacts`. The guard `config["platform"] != "github"` correctly avoids creating a redundant `GitHubSource` when the primary source is already GitHub. The `GitHubSource(gh_repo)` constructor is simple (just stores the repo string), so no risk of side effects during initialization.

---

### ftl_project_expert/cli.py:status
VERDICT: PASS
CORRECTNESS: VALID
SPEC_COMPLIANCE: N/A
ISSUE_COMPLIANCE: N/A
BELIEF_COMPLIANCE: N/A
TEST_COVERAGE: UNTESTED
INTEGRATION: WIRED
REASONING: Straightforward display addition — shows the `github_repo` config value on the dashboard when present. Correctly guards with `config.get("github_repo")`.

---

### Overall
VERDICT: CONCERN
CORRECTNESS: VALID
SPEC_COMPLIANCE: N/A
ISSUE_COMPLIANCE: N/A
BELIEF_COMPLIANCE: N/A
TEST_COVERAGE: UNTESTED
INTEGRATION: WIRED

**Summary of findings:**

1. **No tests** — there are zero test files in this project. The `_fetch_artifacts` function has no test callers. The new `github_source` parameter and init option are completely untested. This is the primary concern.

2. **Minor: issue fallback gap** — When a Jira/GitLab project has `--github-repo` configured, PR refs correctly fall back to `github_source`, but issue refs (e.g., `#42`) still only try the primary source. If the ref came from a GitHub context, the user might expect it to resolve against the GitHub repo too. This is a design gap, not a bug — the exception handler prevents crashes.

3. **The feature works end-to-end for its stated purpose** — a Jira or GitLab project can now configure `--github-repo owner/repo` at init time, and when `research` encounters PR references, they'll be looked up against GitHub instead of silently failing.

---

### SELF_REVIEW
LIMITATIONS: No test files exist in this project at all, so I couldn't verify whether any external/integration test suite covers these paths. Could not see `_get_source` callers beyond `research` to know if other commands (like `scan` or `explore`) also call `_fetch_artifacts` and might benefit from the same `github_source` fallback. The sources module observation initially failed because it's a package (directory), not a single file — I had to locate it manually.

---

### FEATURE_REQUESTS
- Include the full source of imported classes/modules when they're referenced in modified code (e.g., auto-resolve package `__init__.py` re-exports)
- When `test_count: 0` is detected, flag it prominently in the observation results rather than requiring the reviewer to notice the empty list
