Moguru

Dive deeper than Git history.

Comment

Inspiration

GitHub is excellent at preserving what changed, but it is not written for someone trying to understand how a software product became what it is. A repository visitor still has to reconstruct why a subsystem was introduced, which change became a lasting decision, and where the original evidence lives.

Moguru treats GitHub as the source of truth and turns that distributed evidence into a human-readable history book. It does not replace GitHub: every important event remains linked to its canonical Pull Request or commit.

What it does

Moguru ingests a GitHub repository and builds a source-linked narrative from merged Pull Requests, commits, Issues, authors, and code structure.

  • PR-first history: merged Pull Requests are the default historical unit, preserving intent and discussion. Direct commits supplement the analysis without pretending to be PRs.
  • Hierarchical AI summarization: parallel Function/Change tasks aggregate into File, Directory, and Repository summaries.
  • AI-edited History Density: Low Density is selected through batch evaluation plus a repository-wide editorial comparison. Routine automation, weak evidence, missing reasons, and invalid source references are rejected by deterministic validation.
  • Auditable prose: claims and events retain canonical GitHub URLs and fixed SHAs. Source lists stay compact until a reader expands them.
  • Cinematic History Tour: the newest layer begins at the surface. Scrolling dives backward through older turning points; scrolling back returns toward the present. Floating evidence bubbles open the original PR or commit.
  • Optional Research context: users can choose GitHub-only or GitHub plus Deep Research. External context remains supplemental and cannot overwrite GitHub-specific facts or establish unsupported causality.
  • Private repositories: the PoC architecture supports short-lived GitHub App installation tokens.

How we built it

Moguru is a Next.js App Router application with a local worker/orchestration layer, SQLite input snapshots, Three.js for the interactive tour, and Remotion for a deterministic video artifact.

  1. The user selects a repository, PR-first settings, period, history limit, direct-commit supplementation, and Research mode.
  2. The GitHub connector normalizes evidence and preserves source IDs, URLs, authors, labels, dates, and fixed SHAs.
  3. A compressed SQLite snapshot lets later prompt/model experiments reuse the same acquisition instead of spending GitHub rate limit again.
  4. Parallel workers summarize small changes first and aggregate upward through File, Directory, and Repository layers.
  5. Strict JSON contracts and deterministic checks validate source IDs, URLs, dates, SHAs, turning-point reasons, and structured output.
  6. The History Book and History Tour consume the same event/source graph, so the visual layer does not invent a separate history.

For the local PoC, text and structured evidence cross an executor boundary to Codex; the agent is not given an unrestricted repository path. The Codex CLI path is read-only, ephemeral, and schema-constrained. A remote-agent executor strips local paths before sending the task.

How we used Codex and GPT-5.6

Codex was the primary development partner throughout Build Week. It helped implement and test the App Router vertical slice, PR-first GitHub ingestion, persistent input caching, remote-agent boundary, strict output validation, Docker hardening, cinematic tour, source bubbles, and AI turning-point editorial pass.

Inside the product, the configured PoC routes ordinary summaries to GPT-5.6 Luna at high reasoning effort, ambiguous batch work to Luna/xhigh, and repository-wide editorial comparison to Luna/max. A Sol/low route is reserved for selected contradiction or high-risk checks. The agent receives bounded evidence as task data and returns strict structured output.

This is substantive use of both: Codex accelerated the product's implementation and iteration, while GPT-5.6-family routes perform repository summarization and historical editorial selection.

Challenges we ran into

Selecting history that matters

A valid change is not automatically historically important. Taking every Nth event produced noise. Moguru now compares candidates across chronological batches, performs a repository-wide calibration pass, requires an explicit evidence-backed reason, and applies a high threshold before an event enters Low Density.

Working within GitHub rate limits

Parallel model workers cannot imply unlimited GitHub API concurrency. Source acquisition is separated from analysis; PR metadata is fetched before bounded detail expansion, normalized snapshots are reused from SQLite, and the demo favors smaller repositories with bounded PR limits.

Preserving provenance

A beautiful story is not enough if it cannot be checked. Moguru validates model-returned source identifiers against canonical evidence, retains fixed URLs and SHAs, distinguishes GitHub sources from Research sources, and avoids presenting inferred Issue causality as fact.

Safely visualizing old code

Executing arbitrary historical code is risky. The default tour uses clearly labeled UI reconstructions with dummy data. Executable captures require an explicitly approved fixed revision inside a network-disabled, read-only, resource-limited sandbox; arbitrary historical code is not run on the application host.

Accomplishments that we're proud of

  • A working vertical slice from repository registration through analysis, source-linked History Book, density switching, and a scrollable 3D History Tour.
  • Low Density now means repository-wide AI-selected turning points instead of arbitrary sampling.
  • The visual tour and book share one evidence model, including clickable canonical sources.
  • GitHub input snapshots make prompt tuning repeatable without reacquiring the same PR history.
  • The final repository passes 102 automated tests, lint, TypeScript checking, and a production build.
  • The 2:45 English demo video and its thumbnail are generated reproducibly with Remotion.

What we learned

The strongest model workflow was not a single giant prompt. Small parallel summaries, explicit aggregation layers, strict source identifiers, and a final cross-era editorial pass made the result more useful and auditable. We also learned to separate acquisition parallelism from model parallelism: caching and bounded source expansion matter as much as worker count when GitHub is the canonical source.

What's next for Moguru

  • Multi-tenant isolation, encryption, retention controls, and user-managed OpenAI credentials/budgets.
  • Source plugins for Jira, Trello, Notion, Slack, and other decision records.
  • Safer, isolated visual captures for explicitly approved historical revisions.
  • Better public demo datasets and precomputed books for large repositories.
  • Human editorial feedback that improves turning-point selection without weakening provenance.

Build Week work and honest scope

Moguru existed before Build Week and was meaningfully extended during the submission period. The dated repository history documents the new vertical slice, source-plugin boundary, optional Research context, immersive tour, sandbox foundations, PR-first analysis, persistent input snapshots, remote Codex Agent path, cinematic depth UI, density-aware dives, and repository-wide AI turning-point curation.

This remains a local PoC rather than a hosted production service. Judges can use the documented five-minute npm or Docker path. Jira/Trello integrations, production billing, multi-tenancy, and unrestricted execution of historical code are future work. Live Deep Research requires its executor configuration; GitHub-only remains the reliable baseline.

Built With

Share this project:

Updates