alissa-tools-github-orcloop 0.3.5__tar.gz → 0.3.6__tar.gz

{alissa_tools_github_orcloop-0.3.5/src/main/alissa_tools_github_orcloop.egg-info → alissa_tools_github_orcloop-0.3.6}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: alissa-tools-github-orcloop
-Version: 0.3.5
+Version: 0.3.6
 Summary: ALISSA-TOOLS-GITHUB-ORCLOOP
 Home-page: https://alissa.app
 Author: Fahera

{alissa_tools_github_orcloop-0.3.5 → alissa_tools_github_orcloop-0.3.6}/src/main/alissa/tools/github/orcloop/loop.py

@@ -60,6 +60,17 @@ issues the develop daemon can pick up:
   crash BETWEEN create and the ledger write: it leaves an unlabeled (and so
   un-triggered, harmless) orphan issue; this is the accepted trade the O2 state
   design already documents.
+* **The origin task goes `committed -> in_progress`** as soon as its issue
+  exists (issue #30) -- on the create path, on the adopt path, and on the
+  crash-recovery path that completes an earlier release's label -- through the
+  same `AlissaClient.set_status` the close edge opens its pending_validation
+  walk with. `committed` means scoped-in TODO and released work is being worked,
+  so without this a task would read TODO for the entire implementation window
+  and only jump to `pending_validation` at merge. It is a strictly-from-
+  `committed` move (anything further along is left alone -- never a downgrade)
+  and it is NON-BLOCKING: a failed set is a warning, the release stands, and the
+  close edge's walk applies the same transition at merge. See
+  `_mark_in_progress`.
 * **Operator park**: if the operator removes the trigger label from a released
   issue, orcloop NEVER re-labels it (that would override the operator) and
   raises the `parked` escalation once. Park is detected on the close edge,
@@ -92,8 +103,11 @@ titled `autodev: <owner>/<repo>` (`bow_prefix`).
   one line at a time).
 * **Discovery is O(total BOW membership)**, never O(all committed tasks): ONE
   `GET /v1/bodies-of-work`, then one membership read per matching BOW, then one
-  `get_task` per *committed* member (membership rows carry a status but no task
-  number, so the committed gate is applied before spending the detail read).
+  `get_task` per member whose row reads `committed` or `in_progress`
+  (`BOW_RESOLVE_STATES` -- membership rows carry a status but no task number, so
+  that gate is applied before spending the detail read). The second status is
+  not a release candidate: it is how a released task whose detach did not land
+  reads, and the read is what makes the retry reachable at all.
   `list_marked_committed_tasks` is never called on the release path.
 * **All the gates are unchanged**: committed status, the dependsOn gate, lane
   occupancy, priority-then-age ordering, the same mechanical rendering. A
@@ -119,8 +133,10 @@ titled `autodev: <owner>/<repo>` (`bow_prefix`).
   naming the unreadable count, the reason on every held decision, and a skipped
   fallback sweep (which likewise cannot distinguish unattached from unread).
 * **Detach is the TERMINAL act of a successful release** (create-issue ->
-  ledger -> label -> detach), never the first: a crash mid-release leaves the
-  task attached and therefore still discoverable. orcloop NEVER attaches.
+  ledger -> label -> status -> detach), never the first: a crash mid-release
+  leaves the task attached and therefore still discoverable. orcloop NEVER
+  attaches. The status step sits before it and is not coupled to it in either
+  direction, so a status failure can never leave a task attached.
 * **Operator detach = park, and it is terminal.** A detached task simply stops
   being a candidate; nothing re-attaches it and no later pass resurrects it. If
   the operator RE-attaches a task orcloop already released, the dedupe path
@@ -138,7 +154,12 @@ CRASH STORY, per step of the bow-mode release (all resumed by the next poll):
 3. crash after the label, before the detach -- the row is `labeled=1` and the
    task is still attached; the next pass takes the dedupe path and detaches.
    Detach is idempotent server-side (`removed: false` when already gone), so a
-   crash *during* the detach is equally safe.
+   crash *during* the detach is equally safe. Note the status set landed first,
+   so the task arrives at that pass at `in_progress`: the feed's committed gates
+   would judge it as a non-candidate and hold it forever, which is why an
+   already-released member is routed to the dedupe path on the LEDGER's answer
+   before its status is judged at all (`_bow_feed_pass`, and `BOW_RESOLVE_STATES`
+   for the membership-row half of the same gate).
 
 THE SCAN-FALLBACK SWEEP (`scan_fallback_interval`, default hourly, 0 = off)
 is the `bow` feed's level-based safety net: every interval the loop ALSO runs
@@ -252,10 +273,28 @@ log = logging.getLogger(__name__)
 # the dependency (soft/hard) does not enter here -- both hold identically.
 DEP_CLEAR_STATES = frozenset({"pending_validation", "validated"})
 
-# The close edge only mutates a task it left `committed` (or one mid-transition
-# at `in_progress`, from a partially-applied prior pass). Any other status means
-# the operator moved the task by hand -- skip, never fight them.
-CLOSE_EXPECTED_STATES = frozenset({"committed", "in_progress"})
+# The two origin-task statuses the `committed → in_progress` transition moves
+# between. `committed` = scoped-in TODO; `in_progress` = being worked.
+#
+# BOTH edges make exactly this move, through the same `AlissaClient.set_status`:
+# the close edge as the first step of its pending_validation walk, and (issue
+# #30) the release edge the moment the GitHub issue exists. Released to the
+# pipeline IS being worked -- devloop claims a labeled issue within minutes, so
+# a released task that kept reading `committed` until merge would read as TODO
+# to every observer for the whole implementation window. One definition of the
+# transition, so the two edges can never drift on which one they mean.
+TASK_TODO_STATE = "committed"
+TASK_IN_FLIGHT_STATE = "in_progress"
+
+# The close edge only mutates a task the loop itself left in one of these two
+# states. `in_progress` is the NORMAL one since issue #30 -- the release edge
+# sets it the moment the issue exists, so that is how a task in flight reads.
+# `committed` is now the exception rather than the rule: a release-edge status
+# set that failed, a release that crashed before reaching it, or a task released
+# by a dist older than 0.3.6. Either way there is work left to do, and the walk
+# in `_mutate_close` starts from whichever it finds. Any OTHER status means the
+# operator moved the task by hand -- skip, never fight them.
+CLOSE_EXPECTED_STATES = frozenset({TASK_TODO_STATE, TASK_IN_FLIGHT_STATE})
 
 # Priority ordering for the release queue. Unknown/blank priority sorts last
 # (rank 0); ties break on age (older first).
@@ -330,6 +369,24 @@ CLOSE_HANDOFF_STATE = "pending_validation"
 # gate still decides whether the work is ready to leave the queue.
 BOW_RELEASABLE_STATE = "committed"
 
+# The member statuses that earn a `get_task` before being judged. Wider than
+# BOW_RELEASABLE_STATE by exactly one entry, and only since the release edge
+# started setting `in_progress` (issue #30): an ATTACHED task at that status is
+# most likely one of orcloop's own releases whose terminal detach did not land,
+# and the detach retry lives behind the detail read (`_dedupe_result`). Gating
+# it out on the membership row alone would strand it -- attached forever, held
+# once per poll, invisible to the marker sweep (which lists COMMITTED tasks),
+# and unreachable by the only `detach_task` caller there is. The detail read is
+# the price of that recovery, and the bound is one read per poll per member at
+# this status -- no writes, and nothing that scales with the task graph. Two
+# shapes reach it, and only one is transient: an unfinished detach clears on the
+# pass that resolves it (in steady state a released task leaves the feed on the
+# pass that released it), while a task an operator ATTACHED at `in_progress` is
+# held and stays attached, so it earns that read every poll until they detach
+# it. Still the right trade against a permanent strand. Every other status
+# (draft, blocked, cancelled, validated...) is held off the row, unread.
+BOW_RESOLVE_STATES = frozenset({BOW_RELEASABLE_STATE, TASK_IN_FLIGHT_STATE})
+
 # `state.meta` key: unix seconds of the last scan-fallback sweep, so the
 # low-frequency safety net keeps its cadence across daemon restarts (a restart
 # loop must not turn an hourly sweep into a per-boot full scan).
@@ -698,9 +755,13 @@ class Orchestrator:
         sweep needs to measure itself against this pass (see `FeedPass`).
 
         Cost is O(total BOW membership): one list call, one membership read per
-        feed BOW, and one `get_task` per committed member. Uncommitted members
-        are held off the membership row's own status, so the detail read is
-        never spent on work that cannot release anyway.
+        feed BOW, and one `get_task` per member the row reports at a status in
+        `BOW_RESOLVE_STATES`. Every other status is held off the row alone, so
+        the detail read is never spent on work nothing could do anything with.
+        The read IS spent on `in_progress` members, which cannot release --
+        deliberately: that is how an already-released task whose detach failed
+        reads, and the gate below routes it to `_dedupe_result` to finish the
+        detach. Recovering it is worth one read.
 
         Membership is read for EVERY feed BOW before any member is evaluated,
         because a task attached to two feed BOWs has an ambiguous target repo
@@ -840,7 +901,7 @@ class Orchestrator:
                 ambiguous = self._ambiguous_claim(owners)
                 reason = ambiguous or broken
 
-                if member.status != BOW_RELEASABLE_STATE:
+                if member.status not in BOW_RESOLVE_STATES:
                     if ambiguous is not None:
                         log.warning("%s is %s", self._member_slug(member), ambiguous)
                     # Held off the membership row, so no `get_task` and no task
@@ -871,11 +932,31 @@ class Orchestrator:
                 # it: a task moved out of `committed` between the two reads
                 # must not release off a stale membership row.
                 if task.status != BOW_RELEASABLE_STATE:
+                    if task.task_number in released_github or self.state.is_released(
+                        task.task_number
+                    ):
+                        # Not a release candidate at all -- an ALREADY-RELEASED
+                        # task that is still attached is an unfinished detach,
+                        # and since the release edge leaves what it releases at
+                        # `in_progress` (issue #30) this is the shape that
+                        # arrives here. Judging it on its status would hold the
+                        # very task whose detach is waiting to be retried, in a
+                        # state nothing else in the daemon can leave: the ledger
+                        # answer has to come first. Same call the committed path
+                        # makes below, so the retry is the one already
+                        # documented.
+                        results.append(
+                            self._dedupe_result(task.task_number, bow=bow, task=task)
+                        )
+                        continue
+                    stale = (
+                        " — the membership row was stale"
+                        if member.status == BOW_RELEASABLE_STATE else ""
+                    )
                     results.append(self._logged(task.ref, Decision(
                         Action.HELD,
                         f"attached to {bow.title!r} but its task detail says "
-                        f"{task.status!r}, not {BOW_RELEASABLE_STATE!r} — the "
-                        f"membership row was stale",
+                        f"{task.status!r}, not {BOW_RELEASABLE_STATE!r}{stale}",
                         task.task_number,
                     )))
                     continue
@@ -911,7 +992,9 @@ class Orchestrator:
                 if task.task_number in released_github or self.state.is_released(
                     task.task_number
                 ):
-                    results.append(self._dedupe_result(task.task_number, bow=bow))
+                    results.append(
+                        self._dedupe_result(task.task_number, bow=bow, task=task)
+                    )
                     continue
                 assert target is not None  # `broken` is None, so it parsed
                 pending.append((task, bow, target))
@@ -1178,7 +1261,11 @@ class Orchestrator:
         return results
 
     def _dedupe_result(
-        self, task_number: int, *, bow: BodyOfWork | None = None
+        self,
+        task_number: int,
+        *,
+        bow: BodyOfWork | None = None,
+        task: Task | None = None,
     ) -> tuple[str, Decision]:
         """A task the dedupe set already covers. Usually a plain SKIPPED, but a
         ledger row still at `labeled=0` is a create->ledger crash survivor: the
@@ -1190,7 +1277,18 @@ class Orchestrator:
         Seeing an already-released task in the feed at all means it is still
         attached: either a crash landed between the label and the detach, or the
         operator re-attached it. Either way the answer is the same -- never a
-        second issue, just finish the release by detaching."""
+        second issue, just finish the release by detaching.
+
+        The crash-recovery branch completes the ORIGIN STATUS too, because it is
+        completing the very release that never reached it: it applies the
+        trigger label, which arms devloop, so leaving the task `committed` would
+        reproduce exactly the symptom issue #30 was filed for. `task` is passed
+        in by the `bow` feed (which has already read the detail); the `scan`
+        feed reaches this method with a task NUMBER only -- deliberately, so a
+        dedupe hit costs no detail read -- so on that path the read is spent
+        HERE, inside the rare branch. The hot branch below returns first and
+        still reads nothing, and a failed read is a warning, never a hold: the
+        label is what matters and it has already landed."""
         ref = f"TASK-{task_number}"
         row = self.state.release_for(task_number)
         if row is None or row["labeled"]:
@@ -1208,6 +1306,7 @@ class Orchestrator:
             return self._logged(ref, Decision(
                 Action.RELEASED,
                 f"[dry-run] would complete labeling of {slug} (crash recovery)"
+                f"{self._resolved_in_progress(ref, task)}"
                 f"{self._detach(ref, bow)}",
                 task_number,
             ))
@@ -1222,12 +1321,89 @@ class Orchestrator:
             return self._logged(ref, Decision(
                 Action.HELD, f"crash-recovery labeling of {slug} failed: {exc}", task_number,
             ))
+        in_flight = self._resolved_in_progress(ref, task)
         return self._logged(ref, Decision(
             Action.RELEASED,
-            f"crash recovery: applied label to {slug}{self._detach(ref, bow)}",
+            f"crash recovery: applied label to {slug}{in_flight}"
+            f"{self._detach(ref, bow)}",
             task_number,
         ))
 
+    def _resolved_in_progress(self, ref: str, task: Task | None) -> str:
+        """`_mark_in_progress` for a caller that may not hold the task detail.
+
+        The read is spent only where it is called from (the rare crash-recovery
+        branch), and only when the caller did not already have the task. A
+        failed read cannot hold anything -- the issue is filed and labeled by
+        now -- so it degrades exactly like a failed status set: one warning, and
+        the close edge's walk corrects the status at merge."""
+        if task is None:
+            try:
+                task = self.alissa.get_task(ref)
+            except AlissaError as exc:
+                log.warning(
+                    "could not read %s to set it %s after completing its "
+                    "release: %s — the release stands and the close edge "
+                    "applies the same transition at merge",
+                    ref, TASK_IN_FLIGHT_STATE, exc,
+                )
+                return f"; STATUS SET PENDING (→ {TASK_IN_FLIGHT_STATE}: {exc})"
+        return self._mark_in_progress(task)
+
+    def _mark_in_progress(self, task: Task) -> str:
+        """Move a released origin task `committed → in_progress` and return a
+        suffix for the decision's reason.
+
+        Released IS being worked (see `TASK_IN_FLIGHT_STATE`): by the time this
+        runs the issue exists and carries the trigger label, so a developer
+        session is minutes away, while the close edge's status walk only runs at
+        merge -- hours or days later. Without this step the task reads TODO for
+        that entire window.
+
+        Three disciplines, each deliberate:
+
+        * **Transition matrix.** Attempted ONLY from `committed`. A task some
+          other surface has already advanced (a human, a race with the close
+          edge) is left exactly as it is: no downgrade, no illegal
+          `in_progress → in_progress` re-issue, no error -- a silent no-op that
+          returns an empty suffix, so the release reads the same as it always
+          did.
+        * **Never blocking.** A failed set logs a WARNING naming the task and
+          the release proceeds unchanged: the issue exists, the label is on, the
+          detach still runs, and the decision is still `released`. No escalation
+          kind, because the close edge's walk applies this same transition at
+          merge -- the failure is cosmetic and self-healing, and a page that
+          resolves itself is a page that teaches operators to ignore pages.
+        * **Before the detach.** Callers sequence this ahead of `_detach` so the
+          release's terminal act stays terminal. Nothing here couples to the
+          detach in either direction, so a status failure can never leave a task
+          attached to its feed. The converse -- a detach failure meeting a task
+          this method has already advanced -- is why `_bow_feed_pass` consults
+          the ledger before it judges an attached task's status (see `_detach`).
+
+        The mechanism is the close edge's, not a second one: the same
+        `AlissaClient.set_status` call and the same two status constants that
+        `_mutate_close` opens its pending_validation walk with."""
+        if task.status != TASK_TODO_STATE:
+            return ""
+        if self.config.dry_run:
+            return f"; [dry-run] would set {task.ref} {TASK_IN_FLIGHT_STATE}"
+        try:
+            self.alissa.set_status(task.ref, TASK_IN_FLIGHT_STATE)
+        except AlissaError as exc:
+            log.warning(
+                "released %s but could not set it %s: %s — the release stands "
+                "(the issue exists and is labeled) and the close edge applies "
+                "the same transition at merge, so the task is only mis-reported "
+                "as TODO until then",
+                task.ref, TASK_IN_FLIGHT_STATE, exc,
+            )
+            return f"; STATUS SET PENDING (→ {TASK_IN_FLIGHT_STATE}: {exc})"
+        log.info(
+            "%s → %s (released to the pipeline)", task.ref, TASK_IN_FLIGHT_STATE
+        )
+        return f"; task → {TASK_IN_FLIGHT_STATE}"
+
     def _detach(self, ref: str, bow: BodyOfWork | None) -> str:
         """Detach a released task from its feed BOW -- the TERMINAL act of a
         successful release -- and return a suffix for the decision's reason.
@@ -1237,7 +1413,14 @@ class Orchestrator:
         durable in the ledger, and leaving the task attached is the SAFE
         failure -- it stays discoverable, and the next pass's dedupe path
         retries the detach. The reverse (detaching first) would be a take-then-
-        act that could lose the work entirely."""
+        act that could lose the work entirely.
+
+        That retry is only reachable because `_bow_feed_pass` asks the LEDGER
+        before it judges an attached task's status: the release edge runs
+        `_mark_in_progress` before this call, so the task waiting for a retry is
+        `in_progress`, which every committed-shaped gate would otherwise treat
+        as "not a candidate" -- a hold nothing could ever clear, since this is
+        `detach_task`'s only caller and the close edge never detaches."""
         if bow is None:
             return ""
         if self.config.dry_run:
@@ -1513,6 +1696,11 @@ class Orchestrator:
         in-flight whatever orcloop thinks, so there is no trigger to withhold,
         only a ledger row to record and a lane to account for.
 
+        Both branches end at `_mark_in_progress`, like the create path: adoption
+        means the work is (back) in flight, and the already-labeled branch is
+        the strongest case of all -- that issue has been armed for devloop since
+        before this pass ran.
+
         An adopted body is a human's, so it is not the renderer's: only the
         trailer is contractual (it is all the develop daemon reads too). A body
         without the `Autonomous-Dev` trailer is adopted anyway -- the target
@@ -1576,11 +1764,12 @@ class Orchestrator:
             verb = "would record" if labeled else "would adopt"
             unlabeled_note = "" if labeled else f", no {self.config.label!r} label"
             occupancy.setdefault(target, []).append(issue_scope)
+            in_flight = self._mark_in_progress(task)
             return self._logged(task.ref, Decision(
                 Action.SKIPPED if labeled else Action.RELEASED,
                 f"[dry-run] {verb} pre-existing {issue.issue_slug} (carries "
                 f"this task's `Alissa-Task:` trailer{unlabeled_note})"
-                f"{self._detach(task.ref, bow)}",
+                f"{in_flight}{self._detach(task.ref, bow)}",
                 task.task_number,
             ))
 
@@ -1598,11 +1787,16 @@ class Orchestrator:
                 # ran before this issue existed, so no later candidate would
                 # otherwise measure itself against it.
                 occupancy.setdefault(target, []).append(issue_scope)
+                # `skipped` describes what was FILED (nothing), not what is
+                # happening to the work: an armed issue for this task is live,
+                # so the task is in flight exactly like an adopted one.
+                in_flight = self._mark_in_progress(task)
                 return self._logged(task.ref, Decision(
                     Action.SKIPPED,
                     f"already released by hand as {issue.issue_slug} (trailer "
                     f"and {self.config.label!r} label present); recorded in the "
-                    f"ledger, no second issue{self._detach(task.ref, bow)}",
+                    f"ledger, no second issue{in_flight}"
+                    f"{self._detach(task.ref, bow)}",
                     task.task_number,
                 ))
             self.github.add_label(issue.owner, issue.repo, issue.number, self.config.label)
@@ -1619,11 +1813,13 @@ class Orchestrator:
             ))
 
         occupancy.setdefault(target, []).append(issue_scope)
+        in_flight = self._mark_in_progress(task)
         return self._logged(task.ref, Decision(
             Action.RELEASED,
             f"adopted pre-existing {issue.issue_slug} (carries this task's "
             f"trailer, was unlabeled): ledger row recorded and "
-            f"{self.config.label!r} applied{self._detach(task.ref, bow)}",
+            f"{self.config.label!r} applied{in_flight}"
+            f"{self._detach(task.ref, bow)}",
             task.task_number,
         ))
 
@@ -1805,10 +2001,11 @@ class Orchestrator:
         bow: BodyOfWork | None = None,
     ) -> tuple[str, Decision]:
         """Create the issue (unlabeled), record the ledger row, stamp the label,
-        then -- under the `bow` feed -- detach the task from its Body of Work.
-        In that order, and detach strictly last: the label is the develop
-        daemon's trigger and the detach is the release's terminal act, so a
-        crash at any point leaves the work discoverable rather than lost.
+        move the origin task `committed → in_progress`, then -- under the `bow`
+        feed -- detach the task from its Body of Work. In that order, and detach
+        strictly last: the label is the develop daemon's trigger and the detach
+        is the release's terminal act, so a crash at any point leaves the work
+        discoverable rather than lost.
         Occupancy is updated in-memory so a later candidate in THIS pass sees
         the new occupant and respects the lane.
 
@@ -1824,10 +2021,12 @@ class Orchestrator:
 
         if self.config.dry_run:
             occupancy.setdefault(target, []).append(scope)
+            in_flight = self._mark_in_progress(task)
             return self._logged(task.ref, Decision(
                 Action.RELEASED,
                 f"[dry-run] would release to {target} "
-                f"(label {self.config.label!r}){self._detach(task.ref, bow)}",
+                f"(label {self.config.label!r}){in_flight}"
+                f"{self._detach(task.ref, bow)}",
                 task.task_number,
             ))
 
@@ -1848,9 +2047,13 @@ class Orchestrator:
             ))
 
         occupancy.setdefault(target, []).append(scope)
+        # Status BEFORE detach, and outside the try above: the issue is filed
+        # and armed, so nothing from here on may turn this into a non-release.
+        in_flight = self._mark_in_progress(task)
         return self._logged(task.ref, Decision(
             Action.RELEASED,
-            f"released to {issue.issue_slug}{self._detach(task.ref, bow)}",
+            f"released to {issue.issue_slug}{in_flight}"
+            f"{self._detach(task.ref, bow)}",
             task.task_number,
         ))
 
@@ -2025,8 +2228,8 @@ class Orchestrator:
 
         Criteria satisfaction is naturally idempotent (already-satisfied ones are
         skipped), so it needs no gate."""
-        if task.status == "committed":
-            self.alissa.set_status(ref, "in_progress")
+        if task.status == TASK_TODO_STATE:
+            self.alissa.set_status(ref, TASK_IN_FLIGHT_STATE)
         for criterion in task.criteria:
             if not criterion.satisfied:
                 self.alissa.satisfy_criterion(ref, criterion.id)

alissa_tools_github_orcloop-0.3.6/src/main/alissa/tools/github/orcloop/version

@@ -0,0 +1 @@
+0.3.6

{alissa_tools_github_orcloop-0.3.5 → alissa_tools_github_orcloop-0.3.6/src/main/alissa_tools_github_orcloop.egg-info}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: alissa-tools-github-orcloop
-Version: 0.3.5
+Version: 0.3.6
 Summary: ALISSA-TOOLS-GITHUB-ORCLOOP
 Home-page: https://alissa.app
 Author: Fahera

alissa_tools_github_orcloop-0.3.5/src/main/alissa/tools/github/orcloop/version

@@ -1 +0,0 @@
-0.3.5