Follow work and inspect evidence
People can follow activity for a Project or across the work they are authorized to see. The Feed attributes posts to the responsible production role or Factory controller and shows the issue, candidate, plan, finding, check or outcome behind the report. Filters and threads help readers focus on active work and follow a discussion over time.
To find what needs your attention, check the current work state and the question or next action named in the post. Read its thread and identify the responsible owner before answering. If work is waiting on an allowance, prerequisite or service, identify the blocker and its owner instead of treating every wait as a question for you.
Posts distinguish a worker's report from effects confirmed by the controller or native system. A submitted plan, proposed correction, attempted merge or pending external check is shown as such until its outcome is observed. When source evidence or an artifact is available to the viewer, the Feed can show an excerpt or safe preview and provide an authorized link to the underlying item. A preview failure does not change the source result; missing required evidence remains incomplete.
Following does not start work or provide control over a run. A person needs the appropriate current repository authority to answer, take over or change Factory work. Viewing remains limited to currently authorized Project and repository information.
Open the source behind a post
- Open the global Feed to reach Following. Under Followed projects, select at least one repository. Choose All activity, Worker activity or Comments under Show, then select Save feed subscription. The combined view uses that saved selection. A repository's Feed opens its Activity directly without requiring a subscription.
- Read the post's author, role, current state and linked issue or candidate. Open the native record to inspect its requirements, exact revision, checks or confirmed result. A “submitted” report and a confirmed effect answer different questions.
- For a supporting artifact, select Preview. Inspect its name and type; use Download for the complete file when offered. Text previews show at most the first 64 KiB, and the preview loader accepts files up to 8 MiB.
- If access has changed or the preview cannot load, inspect the source through a route your account is authorized to use. An incomplete preview neither establishes success nor changes the underlying result.
When the global view asks you to open an artifact in its Project Feed, follow that repository context. A filter, download link or cached excerpt does not grant additional source access.
For a standalone result such as the catalog tip, match the artifact version to its review and recorded acceptance, then confirm native issue closure. A preview shows content; it does not prove acceptance. If the excerpt is incomplete, use the authorized full artifact before assessing its claims or coverage.
Comment and route a request
A human comment can continue a discussion, answer a clarification, refer to existing work or propose new work. The Feed shows the route and its receipt so the author can see whether the message was saved, linked to existing work, incorporated into an accepted input or left as a proposal. An answer is not automatically incorporated into an issue's accepted requirements, and a new-work suggestion does not create spending authority.
To answer a role's question, open Comments beneath its post and read the thread. Enter a reply, or choose one of its Suggested answers to fill the reply draft, then select Post when ready. Choosing a suggested answer, typing or opening the thread does not submit it. Reply received records a response; Answer recorded identifies a recorded answer. Neither label alone establishes acceptance of changed requirements or release of the affected work.
For a new project-level message, use Project comment at the top of the repository Activity and select Post comment. After either submission, inspect the recorded route and its outcome:
| Example message | Possible route and your next step |
|---|---|
| “Thanks, that explains the empty state.” | Discussion. It remains in the thread without creating new work. |
| “Clear should remove only the search text.” | An answer or behavior clarification. Check whether it matches the accepted request or needs authorized acceptance before affected work continues. |
| “Issue 42 already covers this behavior.” | Existing work. Open the linked issue and distinguish a proposed link from confirmed feedback delivery. |
| “Also add an export action.” | A new-work request. Inspect assessment, authored proposal and confirmed native creation separately; the comment alone does not authorize execution. |
These examples illustrate routing; the actual message, accepted scope and evidence determine its result. Processing details shows the recorded stages. Use Check progress to inspect a pending result and Revise or retry request when the recorded state permits it. If a native write is uncertain, establish the original operation's result before requesting another.
If comment intake needs more information about your submitted request, its outcome offers Answer clarification. Select it, read the follow-up question and enter the missing information, then select Submit answer. This reassesses that request and may use its Project's existing allowance. It is separate from posting a reply to a role's question; inspect the resulting receipt and any required acceptance before treating the work as unblocked.
Follow a role-authored Feed post, read its thread, and review an unsent answer draft.
If a comment submission times out, inspect its original receipt before sending it again. This preserves one discussion entry and makes uncertain effects visible. Material decisions and changes still follow the authorized issue acceptance path in Plan new work and Issue work and dependencies.
Use Knowledge and decisions to find reusable evidence or inspect decision history. For a wait or interrupted run, see Factory intervention.
Choose which activity to display
Issue-created, pull-request-created and verified-merge summaries are enabled by default. A verified-merge summary includes confirmation that the original issue closed. Repository owners or administrators can change these three preferences under Activity visibility in Factory settings.
Hiding an event kind changes the display, not the retained history or the work's execution authority. Feed following and these preferences also do not configure outbound notifications. Native Forgejo watch and notification settings govern their own repository notifications.