Understand your project. Build what matters.
Connect security, architecture, human goals, roadmap, cycles, and a grounded project agent.
Hyperoru / Start here
Hyperoru is a security and development workspace for applications and open source projects. Understand what your repositories contain, how the system connects, which risks deserve attention, and what to build next. Start with a workspace and a project, then connect the tools you choose.
The architecture map is the starting point. Behind it is a model of entities, relationships, evidence, confidence, and coverage. Human decisions add the reasons that the observed system cannot tell you by itself.
One connected project
| View | What you do here |
|---|---|
| Project brain | Record purpose and goals, select sources, and review evidence-linked opportunities |
| Security | Inspect current findings and track the work that addresses them |
| Architecture | Explore entities, relationships, evidence, confidence, and coverage |
| Roadmap | Prioritize, assign, filter, and relate private work |
| Cycles | Focus on a delivery outcome and preserve what carried forward |
| Community | Publish curated features, receive verified votes, and moderate requests |
| Project agent | Ask grounded questions about the system and its plans |
Read your project brain, roadmaps and cycles, community voting, or the agent.
Try the product model
Follow a small system from its map to the evidence behind a changed boundary. Switch the snapshot or remove cloud evidence to see why missing context changes the conclusion.
Follow the relationship.
A public route reaches the API directly.
Entities are the things. Relationships explain the system.
Select an entity to read what connects to it. An arrow has a direction and a meaning; it is more than a line between two boxes.
The service handles application requests and reads from the database. Authentication is delegated to the gateway by a human decision.
- Evidence
- server/database.py:24 · database client
- Recorded confidence
- 96% · code reference and connection configuration agree
Ask why a relationship is believed.
The same claim can have several supporting observations. Inspect the source, location, collection time, and any disagreement before relying on it.
- Code · declared application behavior
server/database.py:24 establishes the database client. infra/ingress.tf:16 declares a direct API route.
- Cloud · observed configuration
An ingress inventory collected on 22 September 2026 corroborates the public API route. This is configuration evidence, not a packet trace.
- CI/CD · delivery context
.gitlab-ci.yml:28 names the deployment target. A pipeline definition alone does not prove a successful production deployment.
People provide intent. Hyperoru preserves it.
“The API delegates authentication” is context. The decision to accept that design, its rationale, and the condition that makes it acceptable must come from a person.
- Named owner
- Maya Chen · fictional platform lead
- Rationale and trade-off
- Avoid duplicate authentication work and reduce request latency; accept dependence on the gateway boundary.
- Required guardrail
- Every external request must pass through the authenticating gateway.
The author and approval are supplied example data. No code observation can establish that Maya made this decision.
A change needs a baseline, current evidence, and a question.
The question here is whether a later public route bypasses the gateway boundary required by the human decision.
The new IaC route and cloud observation support a boundary change. Review that evidence against the ratified decision before choosing an action.
Make what is unknown as visible as what is known.
Coverage describes the evidence available for a particular review. It is separate from confidence in any one relationship.
All three expected source families are present in this example. That does not establish complete cloud-account coverage or runtime behavior. IaC is configuration evidence and remains distinct from a live cloud observation.
The architecture behind the project
| View | The question it helps you answer | What to inspect |
|---|---|---|
| Map | What exists, and what connects to it? | Entities, relationship directions, boundaries, and the selected review. |
| Truth | Why does Hyperoru believe this? | Source observations, recorded confidence, timestamps, and contradictions. |
| Intent | Why did the team choose this design? | A person's decision, rationale, accepted trade-offs, guardrails, and approval. |
| Drift | What changed between comparable observations? | Baseline and current snapshots, source parity, and affected decisions. |
| Coverage | What can this review see, and what is missing? | Observed source families, collection boundaries, freshness, and gaps. |
Findings are part of the evidence you investigate in that context. They do not replace the architectural model.
Choose where to begin
Your first workspace
Create a workspace, choose a source, and understand the first review.
Read your map
Follow a relationship from the diagram to its supporting evidence.
Record human intent
Capture a decision and its guardrails, then have a named person ratify it.
Review architecture drift
Compare observations without mistaking missing coverage for deletion.
Connect what your system uses
Code, cloud, infrastructure as code, and delivery configuration contribute different facts. Select a source below to see what it can establish and what remains unknown.
Start with the application you want to understand.
Connect a selected GitHub, GitLab, or Bitbucket repository, or upload a source archive. A workspace does not require a GitHub account.
- What it contributes
- Services, imports, dependencies, API definitions, calls, and data access found in the submitted revision.
- What remains unknown
- A source snapshot cannot establish the current deployed state or prove that a particular path was exercised in production.
Add observations from the environment.
Use the managed collector with your authenticated AWS, Azure, or Google Cloud CLI and a scoped workspace token. Collection runs in your environment.
- What it contributes
- Bounded resource inventory, provider account identity, supported relationships, collection times, and coverage warnings.
- What remains unknown
- Coverage depends on the collector's supported scopes and permissions. A missing or partial collection does not prove that a resource was removed.
Explain what the infrastructure declares.
Include infrastructure configuration in the repository or archive you review. Hyperoru can connect those declarations to application and cloud evidence.
- What it contributes
- Declared resources, network configuration, policy boundaries, and the configuration supporting an architectural relationship.
- What remains unknown
- A Terraform file or Kubernetes manifest expresses configured state. It does not prove that the configuration was applied; inspect cloud evidence for corroboration.
Connect the code to how it is delivered.
Include pipeline configuration with the source snapshot. Repository merge checks can submit an exact revision for an architecture review.
- What it contributes
- Build and deployment configuration, pipeline relationships, declared targets, and review results attached to a particular revision.
- What remains unknown
- A pipeline file does not prove a successful deployment. Check the specific evidence and observation time before treating a configured target as runtime truth.
For implementation details, read the canonical model, review lifecycle, or versioned API. Hyperoru is a product of Yezz LLC.