alissa-tools-github-orcloop 0.3.8__tar.gz → 0.3.9__tar.gz

{alissa_tools_github_orcloop-0.3.8/src/main/alissa_tools_github_orcloop.egg-info → alissa_tools_github_orcloop-0.3.9}/PKG-INFO

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

{alissa_tools_github_orcloop-0.3.8 → alissa_tools_github_orcloop-0.3.9}/src/main/alissa/tools/github/orcloop/ghclient.py

@@ -127,11 +127,20 @@ class PullRequest:
     body: str
     merged: bool
     url: str
+    # The merge commit's SHA (`merge_commit_sha`), for anchoring the close
+    # evidence to a point in history. Defaulted rather than required: it is
+    # meaningful only on a merged PR, and a payload that omits it must degrade
+    # to "unknown" in the evidence rather than fail the close walk.
+    merge_sha: str = ""
 
     @property
     def full_name(self) -> str:
         return f"{self.owner}/{self.repo}"
 
+    @property
+    def pr_slug(self) -> str:
+        return f"{self.owner}/{self.repo}#{self.number}"
+
 
 class RateLimited(RuntimeError):
     """A `gh` rate-limit signal -- a retry-later condition, distinct from a
@@ -377,7 +386,14 @@ class GitHub:
         """One PR's close-loop-relevant fields, or None if it cannot be read.
         A malformed/empty payload degrades to None rather than a fabricated PR
         -- the close-loop treats "unreadable" as "not the closer, keep
-        looking", never as a merge."""
+        looking", never as a merge.
+
+        `body` and `merge_sha` come from this ONE payload, which is why the
+        close edge's delivery-record evidence (O15) costs no extra round-trip:
+        the PR the close walk already resolved carries everything the evidence
+        needs. A field the payload omits degrades to the empty string here and
+        is reported as missing at the render site -- never fabricated, never
+        fetched a second time."""
         data = self._api(f"repos/{owner}/{repo}/pulls/{number}")
         if not isinstance(data, dict) or not data:
             return None
@@ -390,6 +406,7 @@ class GitHub:
             body=data.get("body") or "",
             merged=bool(data.get("merged") or data.get("merged_at")),
             url=data.get("html_url") or "",
+            merge_sha=str(data.get("merge_commit_sha") or ""),
         )
 
     def _referenced_pr_numbers(self, owner: str, repo: str, number: int) -> list[int]:

{alissa_tools_github_orcloop-0.3.8 → alissa_tools_github_orcloop-0.3.9}/src/main/alissa/tools/github/orcloop/loop.py

@@ -219,6 +219,13 @@ released before a feed switch):
   merged-PR evidence, and move the task `committed -> in_progress ->
   pending_validation` (the two-step transition the status matrix requires;
   orcloop hands off at pending_validation, never validates for the operator).
+  That evidence carries the merged PR's DELIVERY RECORD -- its `## Delivery
+  notes` section, or the whole body when there is none, anchored by PR title
+  and merge SHA (O15, `render_close_evidence`). A task arriving at
+  `pending_validation` has to be validatable from what is attached to it; a
+  bare "closed by <url>" makes the reader re-derive every criterion from
+  GitHub. An unreadable write-up degrades loudly and never blocks the walk --
+  the merge already happened, so holding the close would only strand the task.
 * Closed with NO merged closing PR -> the `closed-unmerged` escalation only;
   the task is NOT mutated (a human closed it, or the work was abandoned).
 * The origin task already moved on (validated/cancelled/blocked/... -- the
@@ -637,6 +644,116 @@ CLOSE_EVIDENCE_BODY = (
     "operator validation."
 )
 
+# O15: the confirmation sentence above is the CLAIM; everything below is the
+# delivery record that lets a validator check it without leaving the task. The
+# two anchor lines are always present, on every path -- a bare slug and URL is
+# what the operator's soft validator rejected on studio TASK-1156925553.
+CLOSE_EVIDENCE_PR_LINE = "**Pull request:** {pr_slug} — {title}"
+CLOSE_EVIDENCE_SHA_LINE = "**Merge commit:** `{sha}`"
+CLOSE_EVIDENCE_TITLE_MISSING = "_(the pull request payload carried no title)_"
+CLOSE_EVIDENCE_SHA_MISSING = "unknown"
+
+# The heading over the included record, in its two shapes. Each names WHICH of
+# the two it is, so the reader never has to guess whether they are looking at a
+# curated section or the whole body.
+CLOSE_EVIDENCE_NOTES_HEADING = "## Delivery notes (from the merged pull request)"
+# "no write-up" rather than "no section": a heading with nothing under it is one
+# of the shapes that lands here, and this heading must not deny it exists when
+# the body below plainly shows it.
+CLOSE_EVIDENCE_FULL_HEADING = (
+    "## Pull request body (no `## Delivery notes` write-up — full body included)"
+)
+
+# The heading the delivery record is written under. Matched line-anchored and
+# case-insensitively, but otherwise EXACTLY: see `extract_delivery_notes` for
+# why this one is strict where O14's context anchors are lenient.
+#
+# WHO EMITS IT: nothing in THIS repo. The producer is the develop daemon's
+# worker directive -- a companion task in the develop-daemon lane, fed the same
+# day as issue #36 and explicitly out of scope for it -- which tells an
+# implementing session to write this section into its PR body. So until that
+# lands, every close legitimately takes the full-body branch; the fallback is
+# the norm today and the section is the arriving case, not the other way round.
+# Both branches are load-bearing and neither is dead code: a PR authored by a
+# human, or by any daemon that never adopts the directive, will always want the
+# fallback.
+DELIVERY_NOTES_HEADING = "## Delivery notes"
+
+# The cap on the included record. Generous on purpose -- a delivery write-up is
+# thousands of chars, and evidence is markdown on a task rather than a GitHub
+# body, so there is no 65,536-char cliff to fit under. It exists so one
+# pathological PR body cannot turn every close into a megabyte write, not to
+# shape the common case. A constant, not a config key, for the reason O14's
+# context caps are: documented caps are a promise, tunable ones are a
+# compatibility commitment.
+#
+# THE HEADROOM IS MEASURED, not assumed, because the size of this write is the
+# one way this feature could newly BLOCK a close: `add_evidence` is not wrapped
+# in `_mutate_close`, `_close_loop` routes its `AlissaError` to
+# `_closeloop_failed`, and `set_status(pending_validation)` comes after it -- so
+# a rejection that is deterministic rather than transient would strand the
+# origin task at `in_progress` on every future poll. `AddEvidenceRequest`
+# declares `markdownContent` with a `minLength` and NO `maxLength`, so the
+# ceiling was probed directly against the live endpoint (2026-07-28, disposable
+# task, since cancelled):
+#
+#     32,300 -> 201     131,072 -> 201     524,288 -> 201
+#     65,536 -> 201     262,144 -> 201   1,048,576 -> 500
+#
+# Worst case here is this cap plus the confirmation line and the two anchors,
+# ~32.3k -- sixteen times under the largest write the endpoint accepted. Raising
+# this constant is therefore NOT a free edit: past ~512k the write starts
+# failing, and it fails in the one direction this feature promises never to
+# fail. Re-probe before widening it.
+CLOSE_EVIDENCE_RECORD_MAX_CHARS = 32000
+# Appended verbatim (issue #36's own wording). No silent caps.
+#
+# The marker ALONE is not the "was anything cut" signal, and the counterexample
+# is this repo's own PR #37: the record is the PR body verbatim, that body
+# mentions the marker inside the very section that gets extracted, and so the
+# first evidence item this feature ever produced would answer a bare-literal
+# grep wrong. `CLOSE_EVIDENCE_TRUNCATED_RE` below is the signal -- deliberately
+# the only place the pattern is written down, because a comment restating it is
+# a second copy to drift from (and, found the hard way, a second copy for a
+# counterfactual to patch instead of the code).
+CLOSE_EVIDENCE_TRUNCATED_MARKER = "[PR body truncated — read the PR]"
+# The signal as a PATTERN rather than as prose: whoever greps an evidence item
+# matches the same thing `_truncate_record` emits, and tests pin both directions
+# so the two cannot drift apart. A promise about a diagnostic is worth exactly as
+# much as the mechanism that keeps it true.
+#
+# ANCHORED at the end, which is what makes the ceiling below exactly true rather
+# than merely nearly so. A real truncation is always LAST in the evidence:
+# `_truncate_record` appends the marker after the record it cut, and
+# `render_close_evidence` appends that record after everything else. Unanchored,
+# a forged line ANYWHERE in a body would read as truncated; anchored, only a body
+# whose own end forges it can. `\s*` before `\Z` so a consumer that normalises
+# trailing whitespace still matches -- trailing blanks cannot forge anything.
+# The end-position invariant this depends on is pinned by a test, so a future
+# change that appends anything after the record fails loudly instead of silently
+# turning a real truncation undetectable. A false NEGATIVE is the worse failure
+# here, exactly as it is for O13's warning.
+#
+# THE CEILING, stated so nobody over-trusts it: a body whose end is a forged
+# marker-and-counts line is indistinguishable from a real truncation. That needs
+# merge access to the target repo, which is the same trust boundary
+# `render_close_evidence` scopes for the included text as a whole -- so it bounds
+# the diagnostic rather than opening a hole to escape.
+CLOSE_EVIDENCE_TRUNCATED_RE = re.compile(
+    re.escape(CLOSE_EVIDENCE_TRUNCATED_MARKER) + r" \(\d+ of \d+ chars included\)\s*\Z"
+)
+
+# The loud degradation. The close walk NEVER stops for this: the merge already
+# happened, and holding the close would strand the origin task in `in_progress`
+# for a missing write-up. (The opposite trade from O14's context hold, where
+# nothing has happened yet and the release can safely wait.)
+CLOSE_EVIDENCE_UNRETRIEVABLE = (
+    "**The pull request body could not be retrieved**, so this evidence carries "
+    "the merge confirmation only — open the pull request for the delivery "
+    "record. The close-loop hand-off proceeded regardless: the merge is a fact "
+    "whether or not its write-up can be read."
+)
+
 
 class Action(str, Enum):
     RELEASED = "released"
@@ -2589,6 +2706,12 @@ class Orchestrator:
           record). A retry after the write succeeded finds the marker and skips,
           so evidence is never duplicated.
 
+        The evidence body itself is the merged PR's DELIVERY RECORD, not a bare
+        merge confirmation -- see `render_close_evidence`. It is rendered from
+        the `pr` object this method was handed, so it adds no call and no
+        failure mode to the walk: a PR whose write-up cannot be read still
+        reaches `pending_validation`, carrying an explicit line saying so.
+
         Criteria satisfaction is naturally idempotent (already-satisfied ones are
         skipped), so it needs no gate."""
         if task.status == TASK_TODO_STATE:
@@ -2600,7 +2723,7 @@ class Orchestrator:
             self.alissa.add_evidence(
                 ref,
                 CLOSE_EVIDENCE_TITLE,
-                CLOSE_EVIDENCE_BODY.format(slug=slug, pr_url=pr.url),
+                render_close_evidence(slug, pr),
             )
             self.state.record_escalation(task_number, CLOSELOOP_EVIDENCE_DONE)
         self.alissa.set_status(ref, "pending_validation")
@@ -3117,3 +3240,263 @@ def render_issue_body(
     """`render_issue(...).body` -- the body alone, for callers with nothing to
     report about how it was rendered."""
     return render_issue(task, target, scope, config, context).body
+
+
+# --- the close edge's delivery-record evidence (O15) -----------------------
+
+# POSSESSIVE quantifiers (`*+`, python >= 3.11, which setup.py already requires)
+# on all three whitespace runs. Greedy `*` makes the tail CUBIC on a line that
+# starts with the heading and then fails: the engine tries every way to split
+# the trailing whitespace across `[ \t]* … [ \t]* … [ \t]*`. Measured on
+# `"## Delivery notes" + " "*n + "X"`: 20ms at n=200, 2.7s at n=800, 24.7s at
+# n=1600 -- and this regex runs inside `_mutate_close`, on a single-threaded
+# poll loop with no timeout, so a crafted body would stall the WHOLE daemon,
+# release edge included, on every poll forever. Possessive quantifiers cannot
+# backtrack, which takes the same n=65,000 input from days to 0.045ms. They are
+# safe here precisely because the three runs are DISJOINT character classes
+# (whitespace / `:` / `#`), so refusing to give text back can never starve a
+# later token: every tolerance case below still matches and every rejection
+# still fails.
+_DELIVERY_NOTES_RE = re.compile(
+    rf"^[ ]{{0,3}}{re.escape(DELIVERY_NOTES_HEADING)}[ \t]*+:?[ \t]*+#*+[ \t]*+\r?$",
+    re.IGNORECASE,
+)
+# A sibling-or-parent heading: `# ` or `## `. A `### ` subsection belongs to the
+# delivery notes and must NOT end them.
+_SECTION_END_RE = re.compile(r"^[ ]{0,3}#{1,2}[ \t]")
+# The delimiter and whatever follows it on the line (the "info string"), which
+# decides whether a fence line can CLOSE a block.
+_FENCE_RE = re.compile(r"^[ ]{0,3}(`{3,}|~{3,})(.*)$")
+
+
+def _fence_scan(lines: Sequence[str]) -> tuple[list[bool], str]:
+    """`(mask, open_fence)` for a markdown document: which lines sit in (or
+    delimit) a fenced code block, and the delimiter still open at the end.
+
+    Both halves come from ONE pass on purpose. A caller that needs to close a
+    block must close it with the delimiter that opened it, and re-deriving that
+    by scanning backwards for "a fence line" is a guess -- the nearest fence
+    line may be an inner one of the other character, or a shorter one, neither
+    of which opened anything. The scan already knows; it hands the answer back
+    rather than making the caller reconstruct it.
+
+    CommonMark's three closing rules, all of which matter here:
+
+    * **Same character.** A `~~~` inside a ``` block is content. Conflating the
+      two ends the block early and hands the code after it back to the heading
+      scan -- the failure the fence tracking exists to prevent.
+    * **At least as long.** ``` cannot close a ```` block, so an inner shorter
+      fence is content too.
+    * **No info string.** ```` ```python ```` opens a block; it can never close
+      one. Without this rule a `## Delivery notes` heading sitting inside an
+      unclosed block reads as a real heading, and because the scan takes the
+      FIRST candidate with content, a fake section early in a body would outrank
+      the real one later -- the one direction this module promises not to err.
+
+    An unclosed fence runs to the end of the document, which errs toward
+    treating more text as code and so toward including more of the body: the
+    same direction as every other tie-break here.
+    """
+    fenced = [False] * len(lines)
+    open_fence = ""
+    for index, line in enumerate(lines):
+        match = _FENCE_RE.match(line)
+        if match:
+            delimiter, info = match.group(1), match.group(2).strip()
+            closes = (
+                open_fence
+                and delimiter[0] == open_fence[0]
+                and len(delimiter) >= len(open_fence)
+                and not info
+            )
+            if closes or not open_fence:
+                # A delimiter line is not content either way; marking it keeps
+                # the line that OPENS a block from reading as a heading.
+                fenced[index] = True
+                open_fence = "" if closes else delimiter
+                continue
+            # A fence line that cannot close the open block IS content.
+        fenced[index] = bool(open_fence)
+    return fenced, open_fence
+
+
+def extract_delivery_notes(body: str) -> str | None:
+    """The `## Delivery notes` section of a pull-request body, or None when the
+    body has no such section with anything under it.
+
+    THE TIE-BREAK, and why it is the opposite of O14's. Both this and
+    `strip_context_section` locate a section by an ambiguous heading, but the
+    costs are mirrored. There, a wrong START anchor SUPPRESSED a diagnostic, so
+    every tie broke toward doing nothing. Here, "do nothing" means falling back
+    to the FULL body -- a strict superset of any section this could have found.
+    Guessing wrong and matching a section costs the reader the rest of the
+    write-up; guessing wrong and matching nothing costs them some scrolling. So
+    the heading match is STRICT: the line, stripped of up to three leading
+    spaces and an optional trailing colon, must be exactly the heading, differing
+    at most in case. `## Delivery notes are still missing` is prose about the
+    notes, not the notes, and reads as absent.
+
+    Strict about the PROSE, tolerant about the TYPOGRAPHY, and the CRLF case is
+    why the distinction matters. This is the only end-of-line-anchored regex in
+    the package -- every other line-anchored parser (`TASK_TRAILER_RE`, the
+    `markers.py` templates, `_SECTION_END_RE`, `_FENCE_RE`) is a prefix match and
+    so already tolerates a trailing `\r`. A PR body edited in GitHub's web UI
+    comes back CRLF-normalised, which would have made every heading read as
+    absent and sent a PR that plainly HAS delivery notes down the full-body
+    branch, under a heading asserting it has none. So `\r` is admitted, as is a
+    closed ATX heading (`## Delivery notes ##`) -- both are the same class of
+    concession as the leading spaces and the case-fold, and neither can turn
+    prose into a match. The scan still splits on `"\n"` and nothing else, for the
+    reason `escape_control_lines` documents: `str.splitlines()` breaks on
+    characters `^` does not recognise and this function JOINS its result back
+    together, so it must not be able to invent a line boundary.
+
+    THE TERMINATOR is the next `# ` or `## ` -- a sibling or parent section.
+    `### ` subsections are kept: a write-up structured as `### What shipped` /
+    `### Verification` under the notes heading is the shape the devloop
+    directive asks for, and ending on the first `###` would take the first
+    paragraph and drop the substance.
+
+    FENCED CODE IS SKIPPED, for both the heading scan and the terminator scan
+    (see `_fence_scan`). A delivery write-up quotes shell and diffs, where a
+    line can legitimately begin with `## `, and a code fence is the one context
+    in markdown where a hash is not a heading.
+
+    EMPTY SECTIONS DO NOT COUNT. A heading with nothing under it is not a
+    delivery record, and returning it would suppress the full-body fallback --
+    the one failure here that actually loses information. The scan therefore
+    continues past an empty candidate to a later one, and answers None only if
+    no candidate has content.
+    """
+    lines = (body or "").split("\n")
+    fenced, _ = _fence_scan(lines)
+
+    for start, line in enumerate(lines):
+        if fenced[start] or not _DELIVERY_NOTES_RE.match(line):
+            continue
+        end = len(lines)
+        for index in range(start + 1, len(lines)):
+            if not fenced[index] and _SECTION_END_RE.match(lines[index]):
+                end = index
+                break
+        section = "\n".join(lines[start + 1:end]).strip()
+        if section:
+            return section
+    return None
+
+
+def _open_fence(text: str) -> str:
+    """The code fence `text` leaves open, or `""` -- the delimiter itself, so
+    the caller can close it with the characters that opened it. Taken from
+    `_fence_scan`'s own tracking rather than re-derived: see there."""
+    return _fence_scan(text.split("\n"))[1]
+
+
+def _truncate_record(record: str) -> str:
+    """`record` capped at `CLOSE_EVIDENCE_RECORD_MAX_CHARS`, with the cut marked
+    where it happened. The counts are appended after the marker rather than
+    inside it so the marker stays greppable as the literal string issue #36
+    named -- and `CLOSE_EVIDENCE_TRUNCATED_RE` is the actual "something was cut"
+    signal, since a PR body may quote the bare literal (see the constant).
+
+    The marker is appended LAST, after the record and after any fence this
+    function had to close. `CLOSE_EVIDENCE_TRUNCATED_RE` is anchored to the end
+    of the evidence on the strength of that, so anything appended after the
+    record -- here or in `render_close_evidence` -- would make a real truncation
+    undetectable. `test_a_real_cut_ends_the_evidence_item` pins it.
+
+    The counts describe what is REALLY there. The slice is `.rstrip()`ed, so
+    reporting the cap would overstate by the whitespace dropped -- a record cut
+    mid-whitespace-run could claim 32,000 chars included and carry seven. Only
+    whitespace is ever lost that way, so this is about the number being exactly
+    true rather than about content. The re-added fence below is NOT counted: it
+    is this function's own text, not the record's.
+
+    A cut that lands INSIDE a fenced code block closes the fence first. The cut
+    is a character slice, so a record whose fence opens before the cap and
+    closes after it would otherwise leave the block open -- and the marker,
+    appended after the cut, would render as program output inside that block.
+    The text is present and greppable either way, so this is about the reader
+    NOTICING, which is the whole claim "no silent caps" makes.
+    """
+    original = len(record)
+    if original <= CLOSE_EVIDENCE_RECORD_MAX_CHARS:
+        return record
+    kept = record[:CLOSE_EVIDENCE_RECORD_MAX_CHARS].rstrip()
+    cut = kept
+    fence = _open_fence(kept)
+    if fence:
+        cut += f"\n{fence}"
+    return (
+        cut
+        + f"\n\n{CLOSE_EVIDENCE_TRUNCATED_MARKER} "
+        + f"({len(kept)} of {original} chars included)"
+    )
+
+
+def render_close_evidence(slug: str, pr: PullRequest) -> str:
+    """The close edge's evidence markdown: the merge confirmation, the two
+    anchor lines, and the merged PR's delivery record.
+
+    Costs no round-trip. `GitHub.closing_merged_pr` already re-fetched the PR to
+    decide it was the closer, and that payload carries the body and the merge
+    SHA -- so the record is assembled from the object the close walk is holding,
+    not fetched again. A second fetch would add a failure mode to a path whose
+    whole point is that it must not acquire one.
+
+    DEGRADE, NEVER BLOCK. Every field is rendered from what the PR object
+    actually has: a missing title and a missing merge SHA each say so in place,
+    and a missing BODY drops the record for
+    `CLOSE_EVIDENCE_UNRETRIEVABLE` -- today's evidence plus an explicit line.
+    None of the three raises, because the caller is mid-`_mutate_close`: the
+    merge has happened, the criteria are satisfied, and an exception here would
+    strand the origin task short of `pending_validation` over a write-up.
+
+    THE INCLUDED BODY IS NOT ESCAPED, and the reason is narrower than "nothing
+    parses evidence". O14 blockquotes control lines because an ISSUE body is
+    read back by orcloop's own line-anchored trailer parsers; task evidence is
+    not -- `add_evidence` is write-only and nothing in this package reads
+    evidence back, so no text arriving here can reach a parser that decides
+    anything. That is the claim, and it is about ORCLOOP. The evidence IS read
+    by the operator's soft validator, which is an LLM, so this text is parsed --
+    just not by anything whose answer moves a task. Anyone adding a machine
+    consumer of evidence inherits no guarantee from this function. Note also
+    what reaching this text costs an attacker: the close edge only fires on
+    issues orcloop itself released, and the body must belong to a PR MERGED into
+    that repo.
+
+    On the empty-body branch being defensive: through today's resolution path a
+    resolved closer cannot have an empty body, because `closing_merged_pr`
+    matched a closing keyword IN that body. That is a guarantee held by another
+    function, and this one's contract -- evidence that never lies about what it
+    contains -- must not depend on it. `GitHub.pull_request` degrades an absent
+    `body` field to `""`, so a payload that omits it, or any future resolution
+    rule that does not read the body, lands here and says so rather than
+    emitting a heading with nothing under it.
+    """
+    parts = [
+        CLOSE_EVIDENCE_BODY.format(slug=slug, pr_url=pr.url),
+        CLOSE_EVIDENCE_PR_LINE.format(
+            pr_slug=pr.pr_slug, title=pr.title.strip() or CLOSE_EVIDENCE_TITLE_MISSING
+        ),
+        CLOSE_EVIDENCE_SHA_LINE.format(
+            sha=pr.merge_sha.strip() or CLOSE_EVIDENCE_SHA_MISSING
+        ),
+    ]
+    body = (pr.body or "").strip()
+    if not body:
+        log.warning(
+            "%s: the merged pull request %s carries no readable body — close "
+            "evidence attached WITHOUT a delivery record (the close-loop "
+            "hand-off is unaffected)",
+            slug, pr.url or pr.pr_slug,
+        )
+        parts.append(CLOSE_EVIDENCE_UNRETRIEVABLE)
+        return "\n\n".join(parts)
+
+    notes = extract_delivery_notes(body)
+    heading = (
+        CLOSE_EVIDENCE_NOTES_HEADING if notes is not None else CLOSE_EVIDENCE_FULL_HEADING
+    )
+    parts.append(f"{heading}\n\n{_truncate_record(notes if notes is not None else body)}")
+    return "\n\n".join(parts)

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

@@ -0,0 +1 @@
+0.3.9

{alissa_tools_github_orcloop-0.3.8 → alissa_tools_github_orcloop-0.3.9/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.8
+Version: 0.3.9
 Summary: ALISSA-TOOLS-GITHUB-ORCLOOP
 Home-page: https://alissa.app
 Author: Fahera

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

@@ -1 +0,0 @@
-0.3.8