Keep Forge progress in one GitHub status comment

.forge/README.md

@@ -13,25 +13,30 @@ its independently recorded checks.
 - **Requested change:** The issue describes the desired outcome. An assigned
   agent reports its plan and useful discoveries as it works. A verified candidate
   becomes a draft PR for review, with separate checks on the proposed merge.
-- **Scheduled check:** Each new occurrence reports in its tracking issue. The
-  current overview shows the latest result; milestone comments preserve the
-  history of individual occurrences.
+- **Scheduled check:** Each occurrence updates the same status comment in its
+  tracking issue. The latest result and a short recent history stay together.
 
 ```mermaid
 flowchart LR
     Human[Contributor PR] --> Checks[Independent checks]
     Request[Assigned issue] --> Agent[Agent work and observations]
     Agent --> Checks
     Schedule[Scheduled occurrence] --> Checks
-    Agent --> Conversation[Context and milestones in GitHub]
+    Agent --> Conversation[One current status in GitHub]
     Checks --> Conversation
     Conversation --> Review[Maintainer review and next decision]
 ```
 
-A current-work comment answers **where are we now?** Separate milestone comments
-explain discoveries, failures, changes of direction, and completion. Each result
-identifies its source revision. Agent observations are distinguished from
-recorded verification; a proposed patch is not a passing result.
+One Forge status comment answers **where are we now?** It is edited as work
+progresses and when checks finish. It explains the current finding and next
+action, with recorded checks and recent activity in a collapsed section.
+New commits reuse that comment. Routine updates do not add notifications.
+Agent observations are distinguished from recorded verification.
+
+The [engineering board](https://github.com/orgs/numinous-technology/projects/1/views/2)
+groups work into Queued, Working, Verifying, Needs review, Blocked, and Done.
+Open a card to read its issue or PR. The comment and GitHub checks contain the
+review details; no separate Forge dashboard is required.
 
 Maintainers choose scope, resolve behavior questions, and decide what merges.
 CI verifies a contributor's code without automatically modifying it. Ordinary

.forge/communication.md

@@ -9,8 +9,14 @@ During work, report findings and changes of approach that matter to review.
 When a candidate is ready, explain the change and remaining concerns. When
 independent checks finish, distinguish observed results from untested claims.
 
-Keep one updated overview and a short history of meaningful milestones.
-Do not post tool-by-tool narration or repeat an unchanged status. When a run
+Keep one status comment per issue or PR and edit it in place. Its current
+explanation must stand alone. Put check details and a short recent activity
+history in a collapsed section. Reuse the comment across new commits and
+scheduled occurrences. Completion updates the comment and check status.
+
+Reserve separate replies for an explicit question or a decision that requires
+a person. Put actionable code findings in a review attached to the relevant
+code. Do not post tool-by-tool narration or routine milestone announcements. When a run
 fails or is interrupted, say what remains unresolved. Never invent a finding
 just to make an uneventful run sound productive.
 
@@ -20,5 +26,5 @@ still needs human review of behavior, test quality, and the merge decision.
 
 A requested change starts in its issue; the generated PR carries the request,
 implementation explanation, actual checks, review focus, and a before/after
-code-flow diagram. Scheduled occurrences retain separate results in their
-tracking issue. Contributor PR descriptions remain the contributor's own words.
+code-flow diagram. Scheduled occurrences retain separate execution results while sharing one
+current status comment in their tracking issue. Contributor PR descriptions remain the contributor's own words.