CoBrain course 03 — Reviewing proposed actions and verifying effects

An action proposal is a plan for a change, not the change itself. Review its target and consequences before any execution, then verify the actual saved effect independently. The examples below teach you to assess a proposal and verify its outcome; they do not represent a task already created by CoBrain.

In this chapter

• Read the whole proposed operation
• Supply complete inputs and an acceptance rule
• Keep native capabilities and manual alternatives distinct
• Define and verify the actual effect
• Report useful limits precisely
• Complete the course with an independent decision

Read the whole proposed operation

Suppose the requested output is a proposal to create a review task for the fictional welcome instruction. The approved brief names the practice Board, exact source version, task output and acceptance rule. It does not authorize creation, assignment, messaging or completion.

Review these dimensions before approving anything:

Dimension	Question
Identity	Correct workroom, module, Board and unique record name?
Source	Exact intended version and complete usable input?
Fields	Title, description, state, date, priority and responsibility match the brief?
Audience	Any assignee, watcher, recipient, CC or sharing change?
Side effects	Could it send, execute, publish, purchase or alter other records?
Authority	Is this specific effect approved, or only a proposal requested?
Verification	What exact record or external result would prove success?

A correct title does not compensate for the wrong Board. A plausible due date does not authorize an assignee. An empty picker does not prove the resulting audience is private or that all responsibility is absent.

Supply complete inputs and an acceptance rule

For the review task, include the full instruction: “Bring one sheet of paper and a pen. Start by drawing Output, Owner and Check boxes.” The task should produce a review that checks both materials and all three labels. It should not claim the review already passed.

If the source instead says “Bring the usual materials,” the missing materials are a real information gap. Do not invent them merely to produce a complete-looking proposal. Ask the owner for the exact intended materials and preserve the unresolved condition.

A proposal saying “create Done task, assign the whole team and notify everyone” adds three effects beyond the requested planning output. Reject those additions and hold execution. General approval to discuss a task is not approval to perform every convenient side effect.

Keep native capabilities and manual alternatives distinct

The visible Act and Act on this controls do not prove a reviewable proposal is available. Historical attempts returned capability/error limitations rather than a successful proposal. A generic incomplete-response error does not by itself establish a subscription problem, missing permission or permanent product defect.

If a future authorized environment returns a real proposal, inspect its actual fields and approval wording. Stop if effects or authority are unclear. Do not press an unverified execution control to discover what it does.

Board's manual Create New Task, Create Task and Update Task workflow is a separate route. A manual saved task does not retrospectively prove CoBrain executed it. Likewise, switching to manual creation can duplicate an uncertain automatic attempt; reconcile the first result before choosing another route.

Define and verify the actual effect

Before a separately authorized save, record the intended Board, unique title, source version and fields. Inspect for an existing matching record. Success of creation means one identifiable task with those retained values; success of the review means the actual review output exists. These may occur at different times.

After an authorized action, record the immediate response, then independently retrieve the exact destination record through its ordinary module. Compare the complete description, state, date, responsibility and relationships. A toast, generated “done” message or timeline event alone is not the full retained-value check.

If a save times out, do not immediately retry. Search for the exact identity, inspect the intended Board's supported list and compare plausible candidates. No search match alone does not prove failure when the relevant list has not been checked. If uncertainty remains, report it to the responsible owner and pause duplicate-prone actions.

Report useful limits precisely

A retained old conversation can be readable while fresh generation is untested. A draft can be reviewed while an action proposal is unavailable. A record can be created while its business work remains undone. State the object and evidence for each conclusion.

A useful issue note includes intended operation, target, source mode, approved brief, observed response, time, known prior effect and the next permitted check. Remove credentials and unrelated personal data. Do not diagnose a backend or plan restriction from an error that does not establish it.

Complete the course with an independent decision

A candidate answer correctly repeats Friday but changes “needs one review” to “approved,” adds a real colleague as owner and proposes creating a Done task. The task save then times out in a hypothetical extension. The correct sequence is to reject the unsupported approval and owner, hold the unauthorized action, and—if an actual save had been authorized and attempted—reconcile the existing destination before any retry.

You have completed the learning sequence when you can choose sources, review the whole answer, inspect authoritative facts, assess a complete proposal and verify effects without turning uncertainty into a false completion claim. Before relying on Act, confirm the actual operation offered and verify its result in the destination.