Set up your project brain
Connect a human project brief with selected sources, architecture, security, and delivery work.
A workspace is your team's shared home. A project is the application or open source system you are building inside it. Each project has its own brief, selected sources, roadmap, cycles, ideas, and agent conversations.
Start with the human part
Open Project brain → New project. Give it a name and a short work prefix, such as AT for Atlas. Work items use that prefix: AT-1, AT-2, and so on. The prefix stays fixed so existing references remain useful.
Record what the project does, who it serves, goals, and constraints. You can create the project with no connected provider and add sources later. Empty architecture or security views mean evidence is missing, rather than that the application is safe.
The brief records a person's goals. It is not an observation of your system or a ratified architectural decision. Use Intent & decisions for decisions with named approval and guardrails.
Choose the observed part
Open Project brief and select repositories, archive reviews, and accepted cloud or tool evidence. The agent and project map use this selection. Two repositories with similarly named components remain separate until evidence establishes a relationship.
Repository sources follow their current observed revision. An archive is a selected review. A cloud collection follows the selected account's source family as new evidence arrives. Removing a source changes the current project context; it does not delete the workspace's historical review.
Connections belong to the workspace. Selecting evidence for a project does not grant extra provider permissions. See source connections.
Read the brain
| Area | What it means | Next action |
|---|---|---|
| Human brief | Your team's stated purpose and constraints | Edit the brief when your direction changes |
| Observed context | Selected sources, observations, and freshness | Open Architecture or inspect source coverage |
| Security | Current findings from those sources | Review the evidence and track work |
| Roadmap | Persistent work, including accepted ideas | Prioritize, assign, and record dependencies |
| Current cycle | The active delivery period and its progress | Review scope and unfinished work |
| Opportunities | Suggestions from goals or observed components | Accept or dismiss with a reason |
Source health can be empty, partial, current, or stale. Current describes the evidence available to Hyperoru; it is not a certification that every part of your system is observed.
Review all recorded security work
Open Security to browse the project's findings in contextual-risk order. Counts and filters apply to the complete selected-source list, independently of the bounded evidence admitted to an agent answer. Load more findings continues through the matching results.
Search by title or rule, then filter by severity, status, or work tracking. Open findings includes new, confirmed, in-remediation, and reopened records. Use the status filter to inspect fixed findings, false positives, and accepted risks. These filters stay in the URL. Refresh findings reconciles source changes and teammates' edits; pagination is a live view, not a historical snapshot.
Needs work item shows findings without roadmap work in this project. Track work creates one private security item; Tracked work opens it for assignment, dependencies, and cycle planning. Work in a different project does not count as tracked here. Completing work does not verify or close the finding: inspect a later source observation to establish the outcome.
Each finding shows its last observation, confidence, and full evidence-record count. Open it to inspect the evidence. An empty filter result says nothing about unobserved sources; review the coverage and freshness information beneath the list.
Turn an idea into a deliberate choice
Choose Find opportunities to produce starting points from the brief and observed components, or ask the project agent a specific question. Ideas explain their basis. An observed API may support the existence of an API, but it cannot establish market demand for a new client library.
Review an idea and record a reason. Acceptance creates one private roadmap item; repeated acceptance cannot create duplicates. Dismissed ideas stay dismissed. If your sources or goals change, refresh stale suggestions before accepting them.
Collaborate without losing edits
Contributors can update briefs and planning work. Viewers can inspect them. Owners and admins manage project archival and public publication. A conflicting revision returns an error; reload the latest version and reconcile the changes instead of overwriting another person's work.
Archiving makes planning read-only and withdraws the public profile. An owner or admin can restore the project from its brief. Restoring does not automatically republish it.