Skip to main content

SC Contractor Task Quality - Review Standard

Purpose​

Defines how to review and close a contractor's work on a ClickUp task. This is the companion standard to SC Contractor Task Quality - Pre-Work Standard: pre-work covers what we hand the contractor; this standard covers what happens when they hand it back.

Bad review patterns -- vague feedback, scope-creep masquerading as bug fixes, inconsistent approve/clarify decisions -- cause errors to repeat across cycles and erode trust in both directions. This doc names the patterns and the choices a reviewer makes at the close of every task.

Scope​

Applies when a contractor moves a ClickUp task to REVIEW status (or its equivalent) and the SC reviewer (typically AM or CEO) reads the work product and decides what to do next.

Section index​

  1. Acceptance Criteria confirmation
  2. Feedback tone — blocking vs. advisory
  3. Decision documentation
  4. Follow-up vs. send-back
  5. Time-entry validation
  6. Quality tagging
  7. Approve vs. clarify

Acceptance Criteria confirmation​

What: Before any other review action, walk every bullet in the task's ## Acceptance Criteria section and mark each as met / not met / partially met.

How:

  • Open the task description and read AC. Skip the chat history — AC is the contract; chat is context.
  • For each criterion, verify it on the actual deliverable (the live URL, the merged PR, the deployed config), not on the contractor's screenshot or report.
  • Mark partials explicitly: a criterion is "partially met" only if the unmet portion is small enough to land as a follow-up (see Follow-up vs. send-back).

Why: A task with ## Acceptance Criteria but no AC walk-through at review time is operationally identical to a task with no AC at all. The walk-through is the only thing that converts AC from theater to reality.

If the task has no AC (i.e., it was assigned before the pre-work standard was enforced): construct AC retroactively from the task description and the chat history, post them as a comment on the task ("Reading AC from the description as: 1...2...3... -- confirming below"), and walk through those. Do not approve a task whose success criteria cannot be stated.

Feedback tone​

Two tones, named explicitly so the contractor can act on them differently.

Blocking feedback​

A defect that prevents closure. Marked clearly: Blocking: or Must fix: at the start of the bullet.

  • Format: Blocking: <what's wrong> -- <how to fix> -- <which AC it violates>
  • Example: Blocking: Carousel uses custom code -- swap for the chosen WP plugin (Smart Slider 3 per spec §2.1) -- violates AC #3 (no custom code).

The contractor cannot close the task until every Blocking item is resolved.

Advisory feedback​

A suggestion that improves the work but does not prevent closure. Marked clearly: Advisory: or Nice-to-have: at the start.

  • Format: Advisory: <observation> -- <suggested change> -- <reason>
  • Example: Advisory: H1 font weight is 600, design kit suggests 700 -- consider bumping unless deliberate -- minor consistency improvement.

The contractor may address advisory items in this task or open a follow-up; their call.

Why the labels matter: Without them, contractors over-rotate on small advisory comments (wasting hours) or ignore blocking comments (forcing a second review cycle). Naming the severity at the start of every bullet removes that ambiguity in one word.

What not to do:

  • "It looks off" -- not actionable; either advisory with a specific suggestion, or blocking with the AC violated.
  • Long unstructured paragraphs mixing 3 blockers and 2 nice-to-haves -- separate into bullets, label each.
  • Sarcasm or rhetorical questions ("did you even read the spec?") -- not feedback, just damage. Replace with the blocking statement.

Decision documentation​

What: When the reviewer makes a judgment call -- accepting a deviation from spec, downgrading a blocker to advisory, deferring an AC item to a follow-up -- the call is documented in the task comments.

Format:

Decision: <what was decided>
Why: <one-line rationale>
Tradeoff: <what was given up, if anything>

Example:

Decision: Accepting H1 weight 600 (spec said 700) for this task.
Why: Design kit was updated to 600 last week; spec is stale.
Tradeoff: Need to update spec in next sprint -- filed follow-up CL-RS-2026-05-001.

Why: Decisions made verbally or in Slack vanish from the audit trail in 90 days. The next contractor reading this task to understand a similar pattern needs to see the call and the reasoning. Comments on the task survive; Slack threads do not.

When to skip: Routine approvals where everything went per spec. The default outcome doesn't need a "Decision: approved" comment; the task status moving to COMPLETE is the artifact.

Follow-up vs. send-back​

A binary at the end of every review: send the task back (move to IN PROGRESS, list blockers) or accept and open a follow-up for any remaining gaps. Don't approve-with-list-of-blockers — that's neither.

Send back (rework)​

  • The task is missing something that was in the original AC.
  • Or, the work product has a defect on a criterion that was actually met-in-spec.
  • The contractor stays on the task; status moves back to IN PROGRESS.

Accept + follow-up​

  • The original AC is met (possibly with documented decisions).
  • New work was identified during review that's adjacent but out-of-scope.
  • The original task closes; new ClickUp task(s) are opened for the follow-up.
  • New tasks reference the original (Follow-up to <task_url>).

Heuristic: if the contractor's last commit could plausibly be the "final" commit on this task, you're in follow-up land. If they need to make more commits to satisfy the original AC, send it back.

What not to do: "Almost done -- can you also add X, Y, Z" as a single feedback dump. That's three scope items disguised as a review. Either send back with the blockers (and let X/Y/Z be follow-ups), or accept and file the three follow-ups explicitly.

Time-entry validation​

What: When approving a task, glance at the contractor's logged time against the estimated-effort.

The validation is light, not forensic:

  • Within ~20% of estimate: no comment.
  • 20-50% over: flag in approval comment, no action. ("Note: logged 5.5h vs. 4h estimate -- carousel debug took longer than expected.")
  • 50%+ over and no explanation: ask. ("Saw 9h logged on a 4h estimate -- can you note what consumed the extra time? Trying to recalibrate estimates.")
  • 50%+ under: also worth checking. ("Logged 1.5h on a 4h estimate -- did anything ship short of full scope?")

Why a light touch: Time entries are not a basis for payment disputes -- they're calibration data for future estimates. Forensic time auditing destroys the trust that the standard depends on. The right reaction to a chronic over-runner is not policing; it's better estimates next time.

Deferred to M7b cron: Automated time-entry hygiene checks (no missing entries, no entries on closed tasks, no entries from before task assignment date) will run as a scheduled symphony-flow job per FR-050. This standard's role is the human review at task close — not the automated drift check.

Quality tagging​

What: When a task surfaces a quality issue — either during this review or after it was previously closed — the reviewer applies the appropriate quality:* tag from the SC ClickUp Tag Taxonomy. The tag is the audit-trail artifact; it persists on the task across reopens.

Three tags, three trigger moments:

  • quality:rework — apply when sending a task back during this review for a blocking defect. The move from REVIEW to IN PROGRESS (per Follow-up vs. send-back §Send back) is the same moment the tag goes on. Remains on the task even after re-close.
  • quality:escaped — apply when a previously-closed task is found defective in the wild (defect surfaced in production, reported by client, caught by a downstream task, or noticed on later review). Apply either by reopening the original task or by tagging a follow-up task that links to the original. Captures the "oversight" case — what AC or validation-evidence-rule should have caught.
  • quality:partial-met — apply when closing a task whose AC walk-through marked one or more criteria as "partially met" by mutual agreement, with the unmet portion deferred to a follow-up or accepted as a known limitation. The decision comment names the unmet portion.

How to apply:

  • Tag in the ClickUp UI (Tags field on the task) or via clickup_add_tag_to_task if doing it programmatically.
  • Tags persist; do not remove them on re-close.
  • The reviewer also leaves a one-line comment explaining the trigger: quality:rework — AC #3 not met (custom carousel code), sending back. This pairs the tag with context so the audit trail is readable.

Why: Tags give us reporting. Per-contractor quality:rework rate, per-domain quality:escaped count, partial-met patterns across a quarter — these surface only if the tagging discipline is consistent. The Quality tag family is small on purpose; resist proposing new variants without a documented recurring pattern.

What not to do:

  • Don't apply quality:rework for advisory feedback. Advisory items are not defects.
  • Don't omit quality:escaped on a follow-up because "the original is already closed." The whole point of the tag is that closed-then-defective is the case we want to count.
  • Don't manually create new quality:* variants in ClickUp. Propose them via PR to the taxonomy first.

Approve vs. clarify​

The final action on a task: approve (close) or clarify (post a comment and wait).

Approve​

  • All AC met (per walk-through)
  • All blocking feedback addressed
  • Time-entry sanity check passed
  • Any deviations documented as decisions

Move the task to COMPLETE. Add a one-line approval comment if anything notable happened (decision documented, follow-up filed). Otherwise the status change is sufficient.

Clarify​

Use when you cannot yet make the approve/send-back call. Examples:

  • AC mentions a behavior that requires production data to verify -- ask the contractor to confirm.
  • A screenshot looks right but you cannot reproduce locally -- ask for steps.
  • The deliverable is in a staging environment you don't have access to -- ask for access.

Post the question as a comment. Leave task status at REVIEW. Do not move to IN PROGRESS (that signals "rework needed" when you actually just have a question).

If clarification reveals work is needed: move to IN PROGRESS with blocking feedback per Follow-up vs. send-back.

If clarification reveals work is fine: approve.

What not to do: Sit on the task without commenting. The contractor cannot tell the difference between "you're thinking about it" and "you forgot". State Reviewing — back in <timeframe> if you need time.

Quick reference​

SituationAction
AC all met, no surprisesApprove, move to COMPLETE
AC met but new scope discoveredApprove + open follow-up task
Original AC unmetSend back with Blocking: bullets, tag quality:rework
Cosmetic issue, AC metAdvisory feedback, approve
Defect found in previously-closed taskReopen or open follow-up, tag quality:escaped
AC partially met, by agreementApprove + tag quality:partial-met, document deferral
Need more info to decideClarify comment, stay in REVIEW
Big estimate overrun, no explanationApprove + ask in comment
Conflicting spec docsApply doc precedence per Markdown Task File to ClickUp SOP §3a

Revision History​

DateVersionChangeAuthor
2026-05-121.0Initial release. Codified the six review concerns: AC confirmation, feedback tone, decision documentation, follow-up vs. send-back, time-entry validation, approve vs. clarify.Symphony Core Systems Team
2026-05-211.1Added Quality tagging section defining when reviewers apply quality:rework, quality:escaped, quality:partial-met from the new SC ClickUp Tag Taxonomy. Updated Quick reference table with corresponding rows.Symphony Core Systems Team