repowise-dev / repowise-dev/repowise

e2e specs are ingested but get no wiki page, so get_answer cannot answer test-infrastructure questions

Open
#1,497 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Python
Stars
6.7k
Forks
711
Avg merge
1d 13h
Merged PRs (30d)
439

Description

Summary

End-to-end test specs are ingested into the graph but never get a file_page, and get_answer searches pages — so any question about test infrastructure is unanswerable, with no signal that a whole area is missing.

Numbers from our repo

TypeScript monorepo, 2,741 files ingested (repowise init . --no-prose):

wiki_pages where page_type='file_page'   2106      (of 2741 files ingested)
apps/*/e2e/** tracked in git               59
  ... of those, with a wiki page            0      <-- none

Ordinary *.test.ts files fare better but are also thinned: 135 of the first 200 have pages.

What it looks like in use

Our Playwright setup is the most heavily documented convention we have — a React hydration gate that every console e2e spec depends on. Asking for it:

"How do console e2e tests avoid clicking server-rendered markup before React has attached?"

get_answer returns confidence: "low" and five fallback_targets, none of them related (apps/console/src/features/harvests/server/harvest.ts, apps/portal/src/shared/session-epoch.ts, …). The two files that answer it — apps/console/e2e/helpers/hydration.ts and apps/console/e2e/fixtures.ts — have no page, so the retrieval cannot reach them. git grep -il hydrat finds them in one attempt.

The information is in the graph: search_codebase in symbol mode does return symbols from these files. Only the page layer is missing.

Why this matters more than a coverage gap

Test files are where a codebase's hard-won conventions live — the gotcha comments, the "we tried X and it broke" notes, the fixtures everyone must use. That is exactly the material an agent most needs and least able to infer. And because the omission is silent, the answer that comes back isn't "I don't have that", it's five confident, wrong files.

Ask

  • If skipping e2e specs is deliberate, could it be surfaced (a note in get_overview / the init summary, or a --include-tests flag)?
  • If it isn't, e2e specs seem worth a page — they're small, high-signal, and already ingested.

I didn't pass --skip-tests; the init summary reported only 2 by .gitignore, 1 by filename pattern, 18 oversized, 11 binary, 4 generated, 79 unknown type as exclusions, which doesn't account for the ~635 file/page gap.

Environment

repowise from main (post-#1454), repowise init . --no-prose --yes, pnpm workspace, 20 packages.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the init ingestion and page-generation flow, then trace how get_answer searches pages and how search_codebase handles symbol results. Compare the treatment of apps/*/e2e/** with ordinary test files and inspect get_overview and the init summary for existing exclusion reporting. Done means e2e coverage is either represented in searchable pages or the omission is clearly surfaced with an intentional option.

Written by the indexing model from the issue text.

Assessment

Tech stack
playwright, python, typescript
Domain
cli, documentation, search, testing-qa
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
55/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.