Skip to content

Reduce the Atlassian skills to Jira, and fix eight broken modules - #1101

Draft
johnml1135 wants to merge 5 commits into
mainfrom
atlassian-skills-fix
Draft

Reduce the Atlassian skills to Jira, and fix eight broken modules#1101
johnml1135 wants to merge 5 commits into
mainfrom
atlassian-skills-fix

Conversation

@johnml1135

@johnml1135 johnml1135 commented Aug 21, 2026

Copy link
Copy Markdown
Contributor

Start here: .claude/skills/atlassian-skills/SKILL.md — the Configuration and Core Workflow sections show the shape of the whole change.

The two Atlassian skills supported Jira, Confluence and Bitbucket. FieldWorks uses Jira. Confluence and Bitbucket are gone — 4,362 deletions against 293 insertions — and nine modules that never worked are fixed.

Where to look:

  • Nine of twelve read-only modules were unusable. Eight raised NameError on import, so any read through them failed and callers reached into the write skill to do a read. The ninth, jira_projects, imported cleanly and raised an unimported NotFoundError only when a project was absent — a successful import is not evidence a module works.
  • The cause was upstream's, and upstream had already fixed it. The bug arrived in cdd1823f6 (2025-12-20) and was fixed in 0fafb48e7 (2026-02-10); d1a9bc66d vendored the pre-fix state on 2026-06-11. Our files are byte-identical to upstream at cdd1823f6 — a stale snapshot, so a re-sync would have fixed this, not reintroduced it. Upstream LT-21672: Add Tables to Word Export #14 is closed as already-fixed.
  • Confluence and Bitbucket removed to the roots — not just the script modules but their docs, config blocks, credential fields, the CQL reference, and the plumbing in _common.py. Zero references outside PROVENANCE.md. What remained was rewritten rather than left with holes, and the read-only variant lost 237 lines of function signatures that REFERENCE.md already documents.
  • Both frontmatter descriptions advertised Confluence and Bitbucket and are rewritten. An overstated description is how the wrong skill gets loaded.
  • PROVENANCE.md records two local modifications that were unlisted: TLS verification is off in three places, because jira.sil.org's certificate chain does not validate here, and the write variant's "no script changes" was untrue.

Deliberately not here: _common.py keeps check_available_skills even though only one service can now be unavailable — load-bearing for the credentials path, cheap to leave.

Verification: pyflakes reports nothing across both variants and all 16 modules import. Live through the read-only skill: jira_get_issue('LT-22723'), jira_get_transitions, and jira_get_project_versions for both a real and an absent project — the last is what the ninth fix buys, and ablating that one import turns it back into a NameError. gitlint clean. No build.ps1/test.ps1: Python utilities outside the build.

Next: review and merge. Independent of #1098/#1099/#1102; #1100 now overlaps by two lines in jira_workflow.py and jira_projects.py, so whichever merges second takes a trivial conflict.


Size before and after
Before After
atlassian-skills (md + py) ~5,900 3,325
atlassian-readonly-skills (md + py) ~4,400 2,219
Script modules per skill 17 9
Broken modules (read-only) 9 0

SKILL.md specifically: write variant 741 → 382 lines, read-only 560 → 148.

What the licence investigation found

Both skills carry license: Complete terms in LICENSE in frontmatter, which is what stopped an earlier pass from touching them at all. Checking properly:

Question Answer
Where from? https://github.com/langpingxue/atlassian-skills, vendored in d1a9bc6
Declared licence? MIT, in the upstream README
LICENSE file upstream? No. GitHub's license endpoint 404s
Copyright line anywhere? No
LICENSE file here? No — the frontmatter reference dangles in both places

MIT permits modification, so the earlier caution was unnecessary. The attribution it does ask for was missing and now exists as PROVENANCE.md in each skill. Since upstream names no copyright holder, a verbatim MIT text could not honestly be authored on their behalf; the provenance files record the declaration and its gaps instead.

This is now a hard fork. A re-sync is no longer a merge — upstream becomes a source to cherry-pick Jira fixes from. PROVENANCE.md says so.

Data Center gotchas captured while investigating

Upstream's docstrings describe Jira Cloud; SIL's instance is Data Center. Three that silently disagree, now in atlassian-skills/PROVENANCE.md:

  • assignee wants a username, not an accountId. jira_create_issue and jira_update_issue both send {"accountId": ...}, which Data Center rejects. Pass custom_fields={"assignee": {"name": "<username>"}}.
  • Affects Version is not exposed at all. Pass custom_fields={"versions": [{"name": "FW 9.3"}]}.
  • resolution cannot be set by an update — not on the edit screen; only a transition sets it.

Each was found by hitting it. They are duplicated into jira-issue/references/publish.md on #1098, where someone working an LT ticket looks first.


This change is Reviewable

confluence_comments, confluence_labels, confluence_pages, jira_agile,
jira_links, jira_projects, jira_workflow and jira_worklog all raised
NameError on import: Optional or AtlassianCredentials was referenced by
a surviving function signature but missing from the import lines. Eight
of the twelve read-only modules were therefore unreachable, and callers
had to fall back to the write skill for reads.

The read-only variant looks generated from the write variant by
stripping write functions, with the stripper also pruning those two
names. The fix restores them and nothing else. It is an upstream bug and
a re-sync will reintroduce it until reported.

Verified: all twelve modules in both skills now import, and
jira_get_transitions returns live data through the read-only skill.

Both skills gain a PROVENANCE.md recording the upstream repository, the
MIT declaration, the local modifications, and the Data Center behaviours
that upstream's Cloud-oriented docstrings get wrong. Upstream declares
MIT in its README but ships no LICENSE file and no copyright line, so
the frontmatter reference to LICENSE dangles there as well as here; it
is left unchanged to keep this copy diffable.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@johnml1135
johnml1135 marked this pull request as draft August 21, 2026 15:41
atlassian-readonly-skills/SKILL.md restated all 48 function signatures
that REFERENCE.md already documents in the same folder, 237 lines of it,
copied from the write variant. It now carries a module-to-function table
naming every function the variant has, and points at REFERENCE.md for
signatures. 560 lines to 265.

The delegation is narrower than it first looked. Only Response Data
Structures, Error Handling and Dependencies are byte-identical between
the two variants and safe to document once; Configuration, Core Workflow
and Philosophy differ, because the write variant carries write examples.
Those first two are kept here verbatim rather than delegated, and the
file says which is which.

Verified: every one of the 48 functions named here is documented in
REFERENCE.md, and the list is generated from the scripts themselves
rather than from the prose it replaces.

Refs LT-22723
@github-actions

This comment has been minimized.

@johnml1135
johnml1135 force-pushed the atlassian-skills-fix branch from 672dc33 to dcd60dd Compare August 21, 2026 15:54
PROVENANCE.md said this skill had deliberately not been compressed. It
has been, in the commit before this one, so the note now records what
changed and warns that a re-sync must re-apply it alongside the import
fix and the SIL section.

The read-only note also cites the upstream issue for the import bug now that one
exists: langpingxue/atlassian-skills#14.

Refs LT-22723

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@github-actions

github-actions Bot commented Aug 21, 2026

Copy link
Copy Markdown

NUnit Tests

    1 files  ± 0      1 suites  ±0   11m 31s ⏱️ +31s
5 864 tests +11  5 783 ✅ +11  81 💤 ±0  0 ❌ ±0 
5 873 runs  +11  5 792 ✅ +11  81 💤 ±0  0 ❌ ±0 

Results for commit f1a4455. ± Comparison against base commit 6f72671.

♻️ This comment has been updated with latest results.

FieldWorks uses Jira and nothing else. Nothing in the repository
referenced a Confluence or Bitbucket helper, yet both skills carried
full support for them: eight script modules each, their documentation,
their configuration blocks, and their plumbing in _common.py.

Removed across both variants: the confluence_* and bitbucket_* modules,
their SKILL.md and REFERENCE.md sections, the CQL query reference, the
partial-service configuration guidance, and in _common.py the dataclass
fields, is_*_available checks, get_*_client factories and the service
branches in AtlassianConfig.from_credentials.

Streamlined what remained rather than leaving holes. Configuration is
now two short modes, SIL Data Center first, with Jira Cloud kept only
for completeness. Core Workflow, the agent-mode example and the
credentials reference were rewritten around Jira instead of having
their other two thirds cut out.

Both frontmatter descriptions claimed Confluence and Bitbucket support,
so they are rewritten too. A description that overstates what a skill
does is how the wrong skill gets loaded.

Verified: zero Confluence or Bitbucket references remain outside the
provenance notes. All 9 modules in each skill import, and a live read
against SIL Jira through the read-only skill still works.

Refs LT-22723
@johnml1135 johnml1135 changed the title Fix eight unusable modules in atlassian-readonly-skills Reduce the Atlassian skills to Jira, and fix eight broken modules Aug 21, 2026
@codecov-commenter

codecov-commenter commented Aug 21, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 38.36%. Comparing base (6f72671) to head (f1a4455).
⚠️ Report is 5 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1101      +/-   ##
==========================================
+ Coverage   38.33%   38.36%   +0.02%     
==========================================
  Files        1507     1507              
  Lines      350580   350634      +54     
  Branches    40293    40304      +11     
==========================================
+ Hits       134410   134505      +95     
+ Misses     186941   186897      -44     
- Partials    29229    29232       +3     

see 12 files with indirect coverage changes

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

johnml1135 added a commit that referenced this pull request Aug 29, 2026
The previous commit repaired all twelve broken modules in both vendored
Atlassian variants. That was the wrong call twice over, and this reverts it.

PR #1101 is open on branch atlassian-skills-fix and already fixes this. It goes
further: it deletes the Bitbucket and Confluence modules outright, reducing both
variants to Jira, and adds a PROVENANCE.md to each. Eleven of the fifteen files
the previous commit touched are files #1101 removes, so the repair was work
against a deletion, and would have conflicted on merge.

The stated cause was also wrong. The names were not pruned locally when we
vendored. Upstream introduced the bug in cdd1823f6 (2025-12-20) and fixed it in
0fafb48e7, "Fix missing imports in readonly variant scripts" (2026-02-10). Our
copy is byte-identical to the pre-fix upstream state, and d1a9bc6 vendored it
in 2026-06-11 -- four months after upstream had fixed it. So this is a stale
snapshot, and the correct remedy is a re-sync from upstream rather than
hand-patching, which is close to what #1101 does.

Kept from the reverted commit: one line in the read-only jira_projects.py,
which also lost NotFoundError. It is raised at :179, inside a function body, so
importing the module successfully does not prove it works -- and this branch
does claim to fix that module, because it deletes the documented workaround for
it. The other fourteen files are back to their vendored state.

This branch now touches exactly two vendored files, jira_workflow.py and
jira_projects.py, which is the minimum for deleting a workaround that named
them. Those two lines overlap #1101; whichever merges second takes a two-line
conflict.
Three corrections to this branch, one of them code.

jira_projects raised NotFoundError at :179 without importing it. Unlike the
eight modules this branch already fixed, that one does not fail at import time,
so "all nine modules import" was true and still insufficient: the module broke
only when a project was absent. Ablation confirms the import is load-bearing --
removing it again turns a clean NotFoundError response into
"NameError: name 'NotFoundError' is not defined". Found with pyflakes, which is
now named in PROVENANCE.md as the check that catches this class of bug. Also
dropped ValidationError from jira_issues, where stripping the write functions
left nothing to raise it.

The recorded cause was wrong. Both PROVENANCE.md files blamed a generator here
that prunes imports while stripping write functions -- hedged as "appears to
be", and never verified. What actually happened is that upstream shipped the
bug in cdd1823f6 (2025-12-20) and fixed it in 0fafb48e7, "Fix missing imports
in readonly variant scripts" (2026-02-10). Our files are byte-identical to
upstream at cdd1823f6, and d1a9bc6 vendored that pre-fix state on 2026-06-11,
four months after the fix existed. So this was a stale snapshot, and the note
claiming "a re-sync will reintroduce it" had it backwards: a re-sync would have
fixed it. Upstream issue #14 was filed against the stale copy and is closed as
already-fixed. What does still hold upstream is the relative import in the four
bitbucket modules, which is moot here now that they are gone.

Two local modifications were unlisted, in a section that opens by asking for
them to be listed. _common.py turns TLS verification off in three places where
upstream leaves it on -- deliberate, because jira.sil.org's certificate chain
does not validate here, so the reason is now recorded rather than left as a
silent diff. And the write variant claimed "no script changes" while this
branch strips Confluence and Bitbucket plumbing out of its _common.py and
__init__.py.

Verified: pyflakes reports nothing at all across both variants, all sixteen
modules import, and jira_get_project_versions was called against live Jira for
both a real project and an absent one.
johnml1135 added a commit that referenced this pull request Aug 31, 2026
Agent-authored LT tickets put good analysis in the wrong shape. The
reference failure opens with a heading, runs past a thousand words,
and states that it contains four separate user-visible problems, so a
triager scanning a queue cannot act on it.

Jira Data Center has no expand macro, so nothing in a description can
be folded away. The skill keeps the description short and moves the
depth into the first comment.

The skill interviews for who, when, where and how under a cap of six
questions, hunts duplicates before drafting rather than before
posting, and gets a three-line lede approved before anything else is
written. Unknowns are recorded rather than guessed, and nothing enters
a description that the reporter did not say or that we did not verify.

compact-style.md is a shared reference adapting the MIT-licensed
i-have-adhd skill from chat turns to written artifacts. pr-pitch now
points at it and gains a Start here line, numbered verification steps,
a closing Next line, an optional status line for long-lived PRs, and
the pre-send check.

jira-bugfix gains the LT-XXXXX-short-slug branch convention, a relaxed
worktree rule that asks rather than refuses, and a note that it is
entered at Step 3 when jira-issue hands off.

Evidence and screenshot handling is deliberately absent; it follows in
a stacked branch.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Skip ticket sections that do not apply to the subject

Not every LT ticket is about FLEx the product. One about developer
tooling, an agent skill, the build or documentation has no FLEx version,
no project file, no menu path and nothing to reproduce inside the
application.

Phase 0b now decides what kind of thing the ticket is about before the
interview starts, and maps that to the environment questions worth
asking. Asking which FLEx build was running, for a ticket about a
Markdown reference file, spends one of six questions and signals that
the ticket was generated rather than written.

The output rule is the same: never emit a section that does not apply. A
template dutifully filled with N/A costs the reader the same scan and
returns nothing, so the heading goes instead.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Move the design record from the tree into the PR body

The design document was a working artifact, not something a future
maintainer needs in order to change this code correctly. Under the
pr-pitch triage it is RESEARCH: a one-time investigation whose
conclusions are now carried by the skill itself.

Its content survives in the pull request body, where the decisions, the
rejected alternatives and the reasoning stay recoverable without
shipping scaffolding into the repository.

Refs LT-22723

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Require Affects Version FW 9.3 on every new ticket

Every new LT ticket carries Affects Version FW 9.3, with no exception.
It is a filing convention that keeps the queue filterable rather than a
claim about which build the reporter was running, so the Phase 0b
relevance rule does not exempt a tooling, build or documentation ticket
from it. A specific point release the reporter names is added alongside
FW 9.3, never in place of it.

Neither jira_create_issue nor jira_update_issue exposes the versions
field, so it goes through custom_fields. The same applies to assignee,
which those helpers send as a Cloud-style accountId that SIL's Data
Center rejects; both fallbacks are now written down where the publish
step needs them.

Refs LT-22723

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Point the worked example at the tickets it actually produced

The example carried placeholder keys for the four symptom tickets that
splitting LT-22715 would create. Those tickets now exist, filed on
2026-08-21 as LT-22724 through LT-22727 and linked back with Issue
split, so the example names them.

A worked example that cites real tickets can be checked by a reader.
One that cites LT-AAAAA cannot, and quietly invites the reader to treat
the whole example as hypothetical.

Refs LT-22715, LT-22723

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Halve the always-loaded skill and record the traps that bit us

SKILL.md goes from 224 lines to 95. It is the only file loaded every
time the skill triggers, so every line it holds is context spent whether
or not the reader needs it. Mechanics move to references, which load
when the phase that needs them is reached.

Moved out: the four duplicate-search passes to a new duplicates.md, the
publish calls to publish.md, the relevance table to format.md. What
stays is the phase table, the two gates, the budgets and the traps.

Recorded from the retroactive rewrite of 28 tickets:

- Link types must be read, never guessed. There is no Relates in this
  Jira, and falling back to the first name in the list produced four
  bogus Cloners links between a cause ticket and its children.
- resolution cannot be set by an update, only by a transition.
- The read-only skill's jira_workflow.py and jira_projects.py raise
  NameError on import; use the atlassian-skills copies.
- A private Gmail or Drive URL in a description is broken evidence.
- Rewriting a ticket posts the original as a comment first.

Task-type tickets gain their own lede labels. Two of the rewritten
tickets were Tasks and had to improvise them.

Refs LT-22723

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Add evidence framework for screenshots in PRs and Jira issues

A visible change should ship with a picture, and the repo already has
the hard half: headless Skia capture for Avalonia, MCP capture for
WinForms, and an Output/ManualEvidence naming convention. What was
missing is the last mile -- trimming, captioning, provenance labelling,
and any route at all from a PNG to a PR body or a ticket.

The rule evidence.md turns on is that the test is the evidence and the
screenshot is the courtesy. A control-level headless capture is not a
screenshot of the product, and every image now says which it is.

Publishing probes three routes and reports the one it used: native gh
attach once it ships, gh image where a session cookie is reachable, and
an orphan evidence branch with sha-pinned raw URLs otherwise. Only the
third works under an Actions token, which is why it stays.

jira_add_attachment uploads to Jira. It drives client.session directly
because AtlassianClient.post sends JSON only, while multipart needs the
XSRF header and no Content-Type. Its validation paths are exercised; the
upload path has not yet been run against a live issue.

A screenshot of a live project is a data disclosure exactly as a project
file is, so the permission gate covers both.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Fix a reference path that does not resolve from its own file

evidence.md sits in .claude/references/ and pointed at
fieldworks-avalonia-ui/references/visual-snapshot-testing.md as if it
were a sibling. The file is under .claude/skills/, so the pointer
resolved from nowhere. Made absolute from the repo root.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Drop the orphan evidence branch from the publish routes

The third upload route proposed creating a never-merged orphan branch to
host screenshots and referencing them by sha-pinned raw URL. It was
speculative, nothing had been built, and it solved a problem lasting one
review by putting binaries in history permanently.

Route three is now the honest one: when no upload path is available, say
which was tried and hand the file to the author to drag in. The skill
also states plainly that images are not committed to the repository and
no side branch is created to host them.

Refs LT-22723

Compress the three workflow skills that carry the most prose

jira-bugfix, pr-preflight and pr-pitch drop from 1107 lines to 374,
about two thirds. A SKILL.md is loaded whole every time its skill
triggers, so every line it holds is context spent whether the reader
needs it or not. Procedure that only one phase needs now lives in a
reference that loads when that phase is reached.

Moved out: the review-summary template, the accordion catalogue, and
the publish-and-verify mechanics.

Deduplicated rather than shortened in place. jira-bugfix carried its own
copy of the JIRA API calls, the assignee and version workarounds, and
the transition rules; it now points at the jira-issue skill's
publish.md. It also delegates commit messages, PR creation and test
coverage to the skills that own them instead of restating them.

Nothing about the guidance changed. The pitch structure, the triage
buckets, the four analysis passes, the interview discipline and every
gate survive verbatim or tightened.

Refs LT-22723

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Repoint nine skill references that resolved from nowhere

Nine cross-references in the Avalonia migration and WinApp skills were
written relative to the skill root while the citing file lives inside
references/, so they resolved to references/references/<name>.md and
pointed at nothing. Every target exists; only the paths were wrong.

Seven become plain sibling names, which is what a file inside
references/ needs to reach the file next to it. Two genuinely cross
skill boundaries and become repo-root paths: winforms-avalonia-parity
cites parity-evidence in the migration skill, and architecture-patterns
cites style-system in the Avalonia UI skill.

Nothing else changed. No prose, no guidance, no file moved or renamed.

Verified by resolving every reference in every .claude markdown file
from the directory it is written in: nine dangling before, none after.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Repair two read-only Jira scripts and correct five skill claims

Review of this PR raised seven items. Six were confirmed against the tree and
are fixed here; the seventh was backwards and is answered instead.

jira_workflow.py and jira_projects.py under atlassian-readonly-skills were
missing two names their own signatures use, Optional and AtlassianCredentials,
so both raised NameError on import. The class is already defined in the
read-only _common.py -- the vendoring generator dropped it from each module's
import list. Both now import, and were run against live Jira. The workaround
telling jira-issue to route around them is deleted: it contradicted AGENTS.md,
which names the read-only scripts as the route for reads.

Ten further read-only modules still fail to import, from the same generator bug
plus a relative-import class in the bitbucket ones. They are left to the
Atlassian transport PR that this branch already defers to.

Also: pr-preflight names the review model again, so the summary template's
field has an owner, and is told never to invent a co-author trailer; pr-pitch
hoists the Start here line to the top of the body, where its own checklist
already required it; jira-issue counts three gates rather than two, because
Phase 5 permission is equally a hard stop; and the assignee username and
Affects Version are derived from the prefs file and Src/MasterVersionInfo.txt
rather than frozen as one developer's name and one release.

Worktree paths in jira-bugfix and dependabot-consolidation now point at
Worktree-CreateFromBranch.ps1 instead of naming a directory. The review placed
worktrees under .claude/worktrees; that path does not exist, and all twelve on
disk are under .tmp/worktrees, so no fixed path written here stays true.

Repair all twelve broken Atlassian modules in both skill variants

The previous commit fixed the two modules a skill documented a workaround for.
Checking the rest found twelve of sixteen read-only modules failing to import,
so this finishes the job and records where the breakage came from.

It came from us. Upstream langpingxue/atlassian-skills is correct: its
read-only jira_workflow.py imports both Optional and AtlassianCredentials.
Our copies arrived in one commit, d1a9bc6 (PR #935), with names deleted from
the import lists -- the signature of an automated unused-import pass that did
not understand names used only inside annotations. Nine modules lost
AtlassianCredentials, five also lost Optional, and jira_projects.py lost
NotFoundError, which import alone does not catch because it is raised inside a
function body. Eight modules are restored to upstream's imports verbatim; the
diff against upstream is now empty for all of them.

The four bitbucket modules are a different defect, and this one is upstream's:
they use "from ._common import", a relative import, in both variants. That can
never resolve under the invocation every SKILL.md documents, which inserts the
scripts directory on sys.path and imports the module directly. They now use the
absolute import and the path shim that the other fourteen modules already use.
This diverges from upstream deliberately, and is worth sending back to them.

Verified: all 33 modules across both variants import, pyflakes reports no
undefined name in either, and five modules that previously raised NameError on
import -- jira_workflow, jira_links, jira_projects, jira_worklog, jira_agile --
were called against live Jira and returned data. Only Jira is configured in
this environment, so the Confluence and Bitbucket modules are verified
statically rather than end to end.

Left alone deliberately: _common.py sets ssl_verify to False where upstream
sets True. That is a local change, not vendoring damage, and reverting it
without knowing why it was made would break every call this repo makes.

Revert the wider Atlassian repair, which PR #1101 already covers

The previous commit repaired all twelve broken modules in both vendored
Atlassian variants. That was the wrong call twice over, and this reverts it.

PR #1101 is open on branch atlassian-skills-fix and already fixes this. It goes
further: it deletes the Bitbucket and Confluence modules outright, reducing both
variants to Jira, and adds a PROVENANCE.md to each. Eleven of the fifteen files
the previous commit touched are files #1101 removes, so the repair was work
against a deletion, and would have conflicted on merge.

The stated cause was also wrong. The names were not pruned locally when we
vendored. Upstream introduced the bug in cdd1823f6 (2025-12-20) and fixed it in
0fafb48e7, "Fix missing imports in readonly variant scripts" (2026-02-10). Our
copy is byte-identical to the pre-fix upstream state, and d1a9bc6 vendored it
in 2026-06-11 -- four months after upstream had fixed it. So this is a stale
snapshot, and the correct remedy is a re-sync from upstream rather than
hand-patching, which is close to what #1101 does.

Kept from the reverted commit: one line in the read-only jira_projects.py,
which also lost NotFoundError. It is raised at :179, inside a function body, so
importing the module successfully does not prove it works -- and this branch
does claim to fix that module, because it deletes the documented workaround for
it. The other fourteen files are back to their vendored state.

This branch now touches exactly two vendored files, jira_workflow.py and
jira_projects.py, which is the minimum for deleting a workaround that named
them. Those two lines overlap #1101; whichever merges second takes a two-line
conflict.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants