Tasks are created against the exact function workspace people are working on, not only against a broad repo or ticket title.
Corrdex shows who is active on the same workspace so people catch collisions before code or ownership drifts apart.
GitHub pushes, checks, docs, issues, and PRs stay attached to the same task so the work remains understandable later.
Tasks
A Corrdex task is the unit of work that ties engineering activity to a real workspace in the codebase. The task is where ownership, comments, push activity, issue links, PR links, checks, and docs all meet.
- A task is created with title, description, assignee, and selected function workspace.
- Tasks are meant to carry work context, not just act as a generic todo row.
- The task detail view is where you see push activity, linked issue state, generated docs, rules, and checks together.
- Tasks can be assigned to yourself or another teammate while still staying attached to the same workspace.
Conflicts
Conflicts are Corrdex’s way of showing when two active workstreams are touching the same workspace. The goal is not to block work. The goal is to make collisions visible while there is still time to coordinate.
- Conflicts appear when multiple active tasks or users overlap on the same claimed workspace.
- They show directly in task detail so the engineer does not have to search another screen to understand what is already in motion.
- If the active person is you, Corrdex should say that clearly. If it is someone else, Corrdex shows their identity so you know who to coordinate with.
- Conflict visibility is most useful before code lands, not after merge pain already happened.
Docs generation
Corrdex can generate workflow-facing documentation from the selected workspace and its surrounding flow. This is meant to capture how work actually moves through the code, not just summarize one file in isolation.
- Docs generation starts from the workspace selected in the task or docs flow.
- If matching workflow docs already exist for that workspace, Corrdex should reuse or surface them instead of generating duplicates.
- Generated docs should stay attached to the same engineering context so future work starts with less rediscovery.
- Docs are a reusable team asset, which is why they are metered separately from tasks and rules in plan limits.
Rules
Rules are standing expectations about how a workflow or code path should behave. They are meant to encode team knowledge once and keep applying it whenever work touches the same area again.
- Rules belong to the project and become shared governance for repeated workflows.
- They are stronger than comments or tribal memory because Corrdex can run them against future changes.
- Free and Pro can have explicit active-rule limits, while Team can remove that cap because rules become part of shared operating behavior.
- Rules matter most when pushes come in and the team wants to validate whether a known invariant still holds.
Checks
Checks are the validation layer that tells you whether the pushed or current code still respects the task’s expectations and standing rules. Corrdex checks are there to catch drift on the actual path being changed.
- Checks can be generated and run against task-linked workspaces.
- Webhook-driven checks matter because they validate newly pushed code, not only stale project state.
- Checks should feel like an automatic code-aware review loop, not like another manual dashboard chore.
- The result belongs on the task because that is where the work and responsibility already live.
Indexing
Indexing is what gives Corrdex the structural understanding it needs to resolve workspace, map code paths, and generate checks and docs with real project context. It is infrastructure, but it supports every user-facing feature above it.
- A project starts gaining Corrdex context after a repository is attached and indexed.
- Indexed files per project is a clean public limit because users understand repository size immediately.
- Reindex should be available when needed, but it should be managed by backend fairness and cooldowns instead of awkward public pricing language.
- Indexing should support the rest of the product quietly in the background rather than becoming the thing users feel they are buying directly.