Explorer

The Explorer provides a direct view into the repository connected to your ORGN project. It allows you to browse source files, review commit history, and manage pull requests without leaving the development workspace.

Unlike external Git interfaces, Explorer is integrated with the ORGN environment. This means that repository activity, agent-generated changes, and task-driven work all remain visible inside the same interface.

Explorer is organized into three main areas:

• Code – browse and inspect the repository structure
• Commits – review commit history and individual changes
• Pull Requests – manage proposed changes before merging

These views give you full visibility into how the repository evolves as tasks are executed and changes are reviewed.

Code

The Code tab shows the current state of the repository at the selected branch.

The interface is divided into two primary sections:

• File Tree – the repository directory structure
• File Viewer – the contents of the selected file

This layout allows you to navigate through the project in the same way you would in a local editor.

Repository Navigation

The file tree displays the full directory structure of the repository. You can expand folders to explore nested directories and quickly locate files across the codebase.

For example, a frontend project may include folders such as:

src/
 components/
 hooks/
 lib/
 pages/

Selecting a file immediately loads its contents in the viewer panel.

The viewer displays:

• file path
• file type
• line count
• full source content

This makes it easy to inspect files without switching tools.

For instance, opening src/pages/Analytics.tsx shows the component structure, imports, and layout used for the analytics dashboard. You can quickly review how components such as CommentFunnel, CompetitorTracker, or EngagementMetrics are composed within the page.

This view is especially useful when:

• reviewing code before executing an agent task
• understanding the structure of an unfamiliar repository
• confirming file contents during a debugging investigation

Because Explorer operates inside the same workspace as agents, you can move from reading code directly into a session or task without switching environments.

Commits

The Commits tab displays the chronological history of changes made to the repository.

Each entry in the list shows:

• commit message
• author
• commit timestamp
• branch information

Commits are grouped by date to make it easier to understand the progression of development activity.

For example, you may see entries such as:

Merge pull request #9 from User/remove-feature

fix: Remove unused feature

feat: Test automated release notes

Selecting a commit opens a detailed diff viewer showing exactly what changed in that commit.

Commit Diff View

When a commit is selected, the interface splits into two areas:

• Changed Files Panel – a list of modified files
• Diff Viewer – line-by-line changes within the selected file

Additions appear in green, while removed lines appear in red.

For example, if a commit modifies new.md, the diff viewer shows exactly which lines were added or removed. This allows developers to quickly review the scope of a change before pulling it into another branch or investigating a regression.

The commit view is useful for:

• tracing when a bug was introduced
• reviewing recent activity in the repository
• verifying the changes included in a merge

Because the commit history reflects both manual commits and merged pull requests, it provides a complete record of how the repository has evolved.

Pull Requests

The Pull Requests tab is where proposed code changes are reviewed and merged.

Instead of pushing changes directly to the main branch, contributors create pull requests that allow others to inspect the modifications before integration.

The pull request view organizes proposals into three categories:

• Open – pull requests awaiting review or merge
• Merged – changes that have been accepted into the repository
• Closed – pull requests that were rejected or abandoned

Each entry displays:

• pull request title
• author
• source and target branches
• change summary (files changed, lines added, lines removed)
• timestamp

This makes it easy to see which changes are currently under review.

Pull Request Details

Opening a pull request reveals a full diff view of the proposed changes.

The interface shows:

• all modified files
• added and removed lines
• commit references
• branch information

For example, a pull request titled “dashboard component clean” may include changes across multiple files such as:

App.tsx
DashboardHeader.jsx
MetricCard.jsx
Sidebar.jsx
CommentFunnel.tsx

The diff viewer allows reviewers to inspect every modification before approving the merge.

A comment panel is also available, allowing team members to leave feedback directly on the pull request.

This enables collaborative review workflows where engineers can discuss implementation details or request revisions before accepting the changes.

Reviewing Pull Requests

Pull requests are created from the workspace, typically after changes are implemented and ready for review. Once a pull request exists, it becomes visible inside the Explorer under the Pull Requests tab.

Explorer acts as the review interface for these changes.

Pull requests are organized into three categories:

• Open – changes currently awaiting review or merge

• Merged – pull requests that have already been integrated into the repository

• Closed – pull requests that were rejected or abandoned

Selecting a pull request opens a detailed view of the proposed changes. The interface displays the full diff across all modified files, including additions and removals, allowing reviewers to inspect the implementation before it is merged.

For example, a pull request such as “dashboard component clean” may include updates across multiple dashboard components. The diff viewer allows you to inspect each file and verify exactly how the implementation changed.

A comment panel is available alongside the diff view, allowing collaborators to leave feedback directly on the pull request. This enables teams to:

• discuss implementation details
• request revisions
• clarify design decisions
• approve the changes before merge

Because pull requests are tied to commits and tasks within the system, reviewers can quickly understand what changed, why it changed, and which work item introduced it.

In practice, Explorer becomes the place where teams review and discuss code changes, while the workspace is where those changes are initially created.

How Explorer Fits Into the Workflow

Explorer serves as the repository inspection and review layer of ORGN.

It allows developers to:

• explore the repository structure
• review commits and historical changes
• inspect pull requests and diffs
• propose and merge code changes

Because Explorer operates inside the same workspace used by tasks, agents, and sessions, developers can move smoothly between planning work, generating changes, and reviewing the final result.

For example, a typical workflow might look like:

1. AI Task Discovery identifies missing test coverage.
2. A task is created to add unit tests.
3. An agent implements the changes.
4. The modifications are proposed as a pull request.
5. The pull request is reviewed inside Explorer and merged.

This tight integration ensures that repository activity remains transparent, traceable, and fully aligned with the task-driven development workflow used throughout ORGN.