Recording Decisions During Coding
Draft, validate, and publish decisions from the IDE workflow without leaving the coding context.
Use this workflow when you are ready to turn implementation context into a decision record without bouncing back to the dashboard for each step. The IDE path is especially useful when the tradeoffs are still fresh and you want the final record to stay close to the code change that prompted it.
What You Need First
Before you start, make sure you have:
- a connected IDE client
- the correct organization, project, and repository context
- enough context to explain the decision, alternatives, and consequences
The main DecisionOps tools used here are:
do-prepare-decision-gatedo-search-decisionsdo-create-decision-draftdo-validate-decisiondo-publish-decisiondo-get-decision
Step 1: Prepare The Context
Start with do-prepare-decision-gate if you want help determining whether the work should create a new record, update an existing one, or skip authoring for now. This is also a good time to run do-search-decisions so the draft can reflect earlier records instead of treating the problem as brand new.
Step 2: Create The Draft
Use do-create-decision-draft to generate a structured draft. The goal is not to accept the first version blindly. Treat the output as a strong starting point that organizes the problem, the chosen approach, and the expected consequences in DecisionOps format.
Review the generated sections carefully. If the draft misses a key risk, assumes the wrong scope, or oversimplifies the alternatives, edit and rerun as needed until the record reflects the real intent of the change.
Step 3: Validate Against Constraints
Run do-validate-decision once the draft is in reasonable shape. Validation checks the draft against organization constraints and other governance rules. This is where you find out whether the decision is complete enough to publish and whether it conflicts with requirements already defined for the workspace.
Validation feedback is often the moment to tighten language, add missing consequences, or clarify why an exception is justified.
Step 4: Publish The Record
When the draft validates cleanly, publish it with do-publish-decision. Publish uses optimistic concurrency, so use the expected version returned by the draft or latest read step. If someone else updated the same record first, you may need to fetch the latest version and retry with the new expected value.
After publishing, use do-get-decision to confirm the final state or open the record in the dashboard if you want richer review tools.
When To Move Back To The Web App
The IDE is great for authoring in flow. The dashboard is still the better choice when you want to:
- compare revision history
- review suggestions in more depth
- approve or supersede a decision with broader visibility
- inspect linked signals from governance or monitoring
What Success Looks Like
The decision publishes successfully, the record is visible in the dashboard, and it is attached to the intended organization, project, and repository scope.
Troubleshooting
If validation fails, update the draft so it satisfies the reported constraints instead of trying to publish around the problem. If publish fails because the expected version is stale, read the latest record and retry with the new version. If the record lands in the wrong place, revisit the org, project, and repository context in your IDE configuration before publishing again.
Search Decisions While Coding
Use this workflow when you want to understand what has already been decided before making a new choice in code. Searching first helps you avoid duplicate records, spot organization-wide defaults, and reuse language or rationale that is already accepted.
IDE Workflow Example
See how an IDE agent can retrieve an existing decision and steer implementation before a conflicting change is introduced.