Task Comments

In LadVen OS, comments are the working history of a task. Participants use them to clarify requirements, ask questions, hand over a result for review, record decisions, and explain why a task was returned for rework or closed.

Use comments not as a general chat, but as a discussion log tied to the task. A few days later, or after the assignee changes, the comments should make it clear what was decided, who should act next, and where the result is stored.

The role of comments in task execution

A task passes through several management stages: assignment, clarification, execution, review, acceptance, and result analysis. Comments connect these stages into one clear scenario.

Use comments as working notes:

• a question shows where the assignee lacks information;
• an answer removes uncertainty and gives a basis to continue;
• a blocker explains why the task is not moving and who owns the next step;
• a decision records the selected option so the team does not return to the dispute;
• a handoff for review shows where the result is and how to accept it;
• a return for rework explains exactly what was not accepted;
• a final comment closes the management context: what was done, what was accepted, and what was moved elsewhere.

This lets a manager avoid collecting statuses in separate chats: the task shows where work stopped, who must respond, and what has already been accepted.

When to write a comment

Write a task comment when the message relates to execution, acceptance, or the history of this task:

• a requirement, deadline, file, checklist item, or readiness criterion needs clarification;
• a participant needs a question with task context;
• an interim or final result has appeared;
• a decision changes the workflow, scope, assignee, or deadline;
• the task is returned for rework, sent for review, closed, canceled, or postponed;
• an explanation must be saved for the requester, assignee, observers, or future review.

For short general discussion without a result link, a chat is more convenient. If the discussion produces a task decision, record the outcome in a separate task comment so it is not lost in correspondence.

What a good comment should contain

A good comment briefly answers the working question: what happened, who must act, and how to verify the result.

Bad comment:

Please take a look.

Better:

@Anna, please check the final table in the attachment: I added the “Payment date” column and filled in the rows for clients from the list. If everything is correct, the task can be closed.

If the comment records a decision, write it as a conclusion, not as a continuation of the argument:

Recording the decision: in the first release we keep manual file review, and move automated reconciliation to a separate related task.

How to record questions

A question should help the work continue, not just mark uncertainty. Formulate it so the addressee can answer without searching for extra context.

A good question structure:

1. What exactly is unclear.
2. Why work cannot continue without the answer or where there is a risk of error.
3. Which options the assignee sees.
4. Who the question is addressed to and when the answer is needed.

Example:

@Marina, please clarify which client list should be treated as final: the May 18 file or today’s CRM export. Without this I may calculate the amount from the wrong base. If there is no answer by 15:00, I will use the May 18 file as agreed.

If the question changes the scope of work, after the answer record the outcome in a separate comment and update the description or checklist.

How to record blockers

A blocker is not just “waiting.” It is a working reason why the task cannot move to the next step.

In a blocker comment, specify:

• what stopped the work;
• which task or checklist item is affected;
• who can remove the blocker;
• what has already been done without waiting;
• when the issue should be checked again.

Example:

Blocker on checklist item 3: there is no final price list from Sales. The draft calculation is prepared, but the final amount cannot be recorded. @Oleg, the file is needed by 12:00 tomorrow, otherwise the task closing deadline will have to move.

Do not pause a task silently. A manager must see not only the delay, but also the dependency that caused it.

Rich text and structure

The comment editor supports rich text. Use formatting for meaning, not decoration:

• lists for several questions, corrections, or review steps;
• emphasis for a key decision, date, restriction, or risk;
• links for documents, external materials, CRM entities, or related tasks;
• quotes for replies to a specific discussion fragment;
• line breaks so a long comment can be scanned quickly.

Do not turn a comment into a new task description. If a comment changes the definition of done, update the description or checklist and leave a comment explaining the reason.

A comment can be long, but should not become too heavy to use. If you need to describe a large result, attach a document or file, and put a short summary and review path in the comment.

Mentions

A mention explicitly draws one person’s attention. Use it when action is expected from the participant: answer, check, approve, attach a file, make a decision, or close a question.

Good pattern:

1. Mention the person.
2. State the specific action.
3. Specify a deadline or condition if important.
4. Attach a link, file, or quote so the person does not need to reconstruct context.

Example:

@Igor, please check checklist item 2.3 by 16:00. I attached a screenshot of the error to the comment.

Do not mention all participants “just in case.” Extra notifications reduce attention to truly important messages. If a person only needs to know the outcome, mention them in the final comment after the decision is made.

Files and inline images

Files and images can be attached to a comment. This is useful when the material explains a specific message: an error screenshot, interim report, approved document version, result image, or file for review.

Attach a file to a comment if it is needed for the question being discussed. General task materials are better stored in the task files block, and evidence for a specific step belongs in checklist item attachments.

An inline image is useful when the image must be seen directly in the comment context: for example, a screenshot of an error, interface state, or review result. After adding the image, check that the needed area is visible and that the filename helps distinguish it from other attachments.

When editing an existing comment, attachments are not added or replaced. If you need to send a new file, leave a new comment with the file and quote the original message if needed.

Quoting and replying

Use quoting when replying to a specific message, checklist item, file, or discussion fragment. This lets participants see exactly what you are reacting to without rereading the whole thread.

Quoting is especially useful when:

• the task has many comments;
• several questions are discussed at once;
• the task must be returned for rework on a specific item;
• a participant replies to something other than the latest message;
• a decision is tied to a separate file or checklist item.

A good quoted reply contains not only agreement or disagreement, but also the next step:

I agree with the note about the calculation. I am correcting the formula and will attach the new file version in a separate comment.

If the discussion has become large, record the outcome in a separate comment without a quote so it is easy to find.

Editing

Edit a comment when you need to fix a typo, clarify wording, or add a missing detail immediately after publishing. The edit window is limited: the current guideline is 30 minutes after sending.

Do not use editing to quietly change an accepted decision or the discussion history. If the comment has already been read or acted on, it is better to leave a new comment:

Clarification to the previous comment: we check only clients from list A; list B goes to a separate task.

While editing, check that after saving the comment still makes sense without hidden context. If saving fails, refresh the task and make sure participants see the current version.

Deleting

Deleting a comment is a risky action because it removes part of the task’s working history. Delete a comment only if it was sent by mistake, contains the wrong file, duplicates a message, or reveals information that should not be in the task.

If a comment contains a decision, question, return reason, or review result, do not delete it. Leave a new correction comment:

The previous decision has changed: the client confirmed the second layout option. We continue using file v2.

Before deleting, check that important information has been moved to the description, checklist, task file, or a new comment.

Reactions

If reactions are available in a task, use them for a short signal without a new message: accepted, seen, agreed, needs attention. A reaction does not replace a comment when an action, decision, reason, or verifiable result is needed.

A reaction is appropriate when:

• you need to confirm that the message was read;
• a participant agrees with the proposal without additional conditions;
• there is no need to create a new text notification;
• the discussion already contains the full context.

Do not close important questions with only a reaction. If further work depends on it, write a short comment: “Agreed, we take option B.”

New comments and read marks

New comments can mark a task as unread and appear in notifications. Read marks help participants see where new messages appeared and return to the last viewed place.

Check unread tasks at the start of the workday, before accepting a result, and before closing a task. If a task is marked unread, read new comments first and only then change the status or accept the result.

If a message is important for a specific person, do not rely only on the general unread indicator. Mention the participant and state the expected action.

Connection with activity and notifications

Comments and activity solve different tasks:

Section	What it shows	When to look
Comments	Discussion, questions, decisions, files, and participant replies.	When you need to understand the meaning of the work, ask a question, accept or return a result.
Activity	Task events: status, deadline, participant, field, notification, and other system changes.	When you need to reconstruct what exactly changed and when.
Notifications	Signals to participants about new comments, mentions, changes, and events.	When you need to understand who should have received information.

If a status changed without a clear comment, activity shows the fact of the change, but not the reason. For important changes, leave a comment: why the deadline moved, why the task was returned, why the result was partially accepted, or why the work was canceled.

Recording a decision

A decision should be easy to find. Do not hide it in the middle of a long discussion, especially if it changes the scope, definition of done, deadline, participants, or acceptance method.

Write a summary comment when:

• discussion ended with a selected option;
• the requester changed the definition of done;
• the assignee proposed a limitation and it was accepted;
• part of the work was moved to a related or child task;
• the result was accepted with reservations;
• the task was canceled, deferred, or closed unsuccessfully.

Good summary comment:

Recording the outcome: we accept option B because it does not require template rework. We do not do option C in this task; I created a related task to estimate automation.

If the decision affects execution, update not only the comment but also the task itself: description, checklist, deadline, participants, related tasks, or files.

Comments for acceptance

Acceptance must answer whether the task can be considered complete by the agreed criteria. Comments are needed by both the assignee and the reviewer.

When handing over the result, the assignee writes:

• what exactly is ready;
• where to open the result: file, link, attachment, related entity;
• which checklist items are closed;
• which limitations or assumptions remain;
• who should be involved in review.

Example:

@Elena, sending for review. The final May report is ready: file “Report_May_v3” is attached to the task, checklist items 1-4 are closed. Limitation: data for client “Sever” is not included because the contract is not signed yet; I moved this to a related task.

The reviewer writes not just “accepted,” but the management outcome:

Accepted and closed. The final report matches the checklist, and file v3 is the working version. Data for client “Sever” is controlled in the related task.

If the result is not accepted, the comment must contain specific corrections and conditions for repeat acceptance.

Practical acceptance templates:

Assignee:
Ready for review. Result: [what was done]. Check here: [file/link/checklist item]. Final version: [file name]. Not included in this task: [limitation or new scope].

Manager:
Accepted. Checked [criteria/file/checklist]. Final version is [name]. Open limitations: [if any]. New scope was moved to related task [if any].

Return:
Returned for rework. Fix [specific block], check [where to look], and send for acceptance again with [expected result].

These comments help the business owner and department manager understand why the task is closed, where the result is stored, and whether new obligations were hidden in the discussion.

Manager control through comments

A manager does not need to ask every participant for a separate status if the team maintains task comments correctly. It is enough to open the task and check four things:

• whether there is a clear last step: who is acting now and what they must do;
• whether there are open questions without answers;
• whether there are blockers with an owner and removal deadline;
• whether important changes have comments: deadline, status, assignee, scope, or acceptance.

If a task is overdue but comments contain a blocker, owner, and next review time, the situation is managed. If there are no comments, the manager sees not a process, but only a silent delay.

For regular control, agree with the team that every deadline change, return for rework, acceptance with reservation, and dependency on another department must have a comment in the task.

Comments when returning and closing

When returning to work, a comment is required in practice: the assignee must understand exactly what to fix and how to pass review again.

Bad return:

Redo it.

Good return:

Returned for rework: the final file has no calculations for clients from group B. Add rows from the list, recalculate the total amount, and send for review again.

A closing comment is not always required, but it is useful if the task matters for history, a report, a client, or context handoff. Write what was accepted, where the final version is, and which limitations remain.

Example:

Accepted and closed. The final presentation version is attached to the task, and corrections from comments are included. We move automated export to a related task.

Step-by-step scenarios

Ask the assignee a question

1. Open the task.
2. Go to comments.
3. Briefly describe the question and context.
4. Mention the assignee or another participant whose answer is needed.
5. Attach a file, link, or image if the question is incomplete without it.
6. Send the comment.

Check the result: the comment appears in the feed, the mention is displayed correctly, attachments open, and the task is marked unread for the right participants or sent to notifications according to LadVen OS rules.

Hand over the result for review

1. Make sure the result matches the description and checklist.
2. Attach the final file, link, document, or screenshot.
3. Write a comment: what is ready, where to check it, and whether there are limitations.
4. Mention the reviewer if action is required.
5. Move the task to the review state if the process expects it.

Check the result: the reviewer sees the comment, the final material is available, the task status matches the process, and the comment does not contain a vague “done” without a review path.

Reply to a specific note

1. Find the comment or item you are replying to.
2. Use quoting or reply.
3. Write what you did or why you propose another option.
4. If there is a new file, send it in a new comment.
5. If the note is closed, record that explicitly.

Check the result: the reply is next to the context, the participant understands which note is closed, and the new file version differs by name or description.

Return a task for rework

1. Check the result, files, checklist, and latest comments.
2. Formulate a concrete list of corrections.
3. Mention the assignee if you need to draw attention.
4. Write how to check the correction after repeat submission.
5. Change the task status to a working state or another suitable return status.

Check the result: the return reason is visible in comments, corrections are listed separately, the task status does not look closed or accepted, and the assignee has a clear next step.

Record a final decision

1. Wait until the discussion reaches a decision.
2. Write a separate summary comment.
3. Specify the chosen option, rejected options, and the reason if important.
4. Update the description, checklist, deadlines, participants, or relations if the decision affects work.
5. Mention participants who need to know the outcome if needed.

Check the result: the decision can be found without reading the entire discussion, the task reflects the new state, and related tasks are created or updated.

Report a blocker

1. Check that the work really cannot continue without external action.
2. Write what stopped the task and which result is at risk.
3. Specify the blocker owner: person, department, client, or related task.
4. Write what has already been done and what can continue in parallel.
5. Specify the next review time or conditions for removing the blocker.

Check the result: the manager sees the reason for the stop, the person responsible for removing the blocker is mentioned, and the task does not look forgotten.

States and limitations

• Old comments may load through a separate action. After loading them, check that you are replying to the current message.
• During sending or file upload, do not close the task until the saving indicator disappears.
• If an action is unavailable, check task permissions and participant role.
• If LadVen OS says the action is unavailable, check task permissions, participant role, and work status.
• If another participant changed the data, refresh the task and check the current comment or task state before retrying.
• The current editing guideline is 30 minutes after sending.
• The current guideline for one comment text block is 4096 characters. For large material, use a file and a short summary.
• Attachments are not added in edit mode. Send a new file in a new comment.

Good practices

• Write the comment where the work is: in the task, not in a private chat.
• Mention a person only when action or a decision is required.
• Record decisions in a separate summary comment.
• Separate question, blocker, decision, and acceptance into different comments if they are different management events.
• For every open question, specify the addressee and expected answer time.
• For a blocker, write the dependency owner and next step, not only “waiting.”
• For return to rework, list specific corrections.
• For handoff to review, write what is ready and where to check it.
• During acceptance, record which file or result version is final.
• Attach files where they are needed: to the comment, task, or checklist item.
• Use quoting for focused replies and a summary comment for the decision.
• Do not change history through editing if someone has already started acting on the message.
• Before closing a task, read new comments and check unread messages.

What to check after sending

• the comment appeared in the feed and reads without hidden context;
• mentions are displayed correctly;
• attachments are uploaded, open, and have understandable names;
• the inline image shows the needed area;
• the quote or reply points to the correct message;
• an important decision was not left as a reaction only;
• the task status matches the written comment;
• unread messages are handled before closing or acceptance;
• task activity confirms system changes, and comments explain their reason;
• after refreshing the page, the comment, files, and read marks look expected.

Common mistakes

Writing in a private chat instead of the task. The decision is lost, and a new participant cannot see the history.

Sending “done” without a result. The reviewer must understand what is ready and where to open it.

Returning a task without a correction list. The assignee does not know what to fix, and the task is returned again.

Mentioning all participants without a reason. Extra notifications reduce attention to important messages.

Hiding a decision in a long discussion. The outcome should be a separate comment and, if needed, reflected in the description or checklist.

Using a reaction instead of approval. A reaction can confirm attention, but it does not record a working decision.

Editing an old message instead of a new clarification. The history becomes unclear to those who already read the original version.

Deleting a comment with a decision. It is better to leave a new correction comment so the history stays understandable.

Attaching files without explanation. Participants must understand what version it is, why it is needed, and how to check it.

Closing a task with unread comments. New messages may contain a question, blocker, rejected decision, or new result version.

Treating silence as agreement. If a decision matters for a deadline, money, a client, or acceptance, it must be confirmed in a comment.

Writing about a blocker without an owner. “Waiting for data” does not help manage the task. Specify who provides the data and when to return to the issue.

Accepting a result without a version. A month later it will be unclear which file, link, or document was final.

Needed screenshots

For public documentation about comments, screenshots should show not only the interface, but also the working scenario:

• general comment view in a task with several messages, an attachment, and a mention;
• a comment with a recorded decision after discussion;
• a blocker comment with a mentioned responsible participant;
• result handoff for review with a file or link;
• return for rework with a concrete list of corrections;
• quoting or replying to a specific note;
• state with new or unread comments;
• mobile comment view if managers often check tasks from a phone.

The localized base screenshot is tracked in screenshot-manifest.json as tasks.view.comments-light-desktop. Additional screenshots can be added as separate scenarios when the corresponding demo states are prepared.

Related scenarios

• Add a checklist
• Review and close a task
• Assign participants
• Chats and comments