byteb4rb1e.utils.saas.forgejo exists as a thin layer over byteb4rb1e.utils.http.client, mirroring the Bitbucket wrapper's operations against the Forgejo REST API (api/v1): token auth headers, repository existence check, repository creation under the authenticated user or an organization. No instance URL is hardcoded: every operation takes a host parameter. Both SSH and HTTPS clone URL construction are exposed. Unit tests cover all operations and pass via tox; no new mypy errors beyond the repo baseline.
HttpSession (cookie persistence via http.cookiejar, GET with query params, form-encoded POST, default/per-request header merging, HTTPError-to-response conversion) and the HttpResponse frozen-dataclass refactor live on feature/20 as separate refactor and feat commits. 14 new unit tests covering HttpResponse semantics and HttpSession behavior pass via tox -e unit-py313; the test file adds no new mypy errors beyond the repo-wide baseline. develop working tree clean of http/client.py changes.
byteb4rb1e.utils.config (INI loading/writing, per-flag CLI integration, dotted-path --config KEY=VALUE overrides, help formatting) and byteb4rb1e.utils.argparse.actions.KeyValueAction with package export live on feature/19 in five granular commits (production code before tests, module boundaries separate). 46 unit tests pass via tox -e unit-py313. develop working tree clean of these files.
HttpSession and the HttpResponse frozen-dataclass refactor live on branch feature/20 as separate refactor and feat commits; unit tests covering HttpResponse and HttpSession (cookie persistence, header merging, params, form POST, HTTPError handling) added and passing via tox; develop working tree is clean of http/client.py changes.
byteb4rb1e.utils.config and byteb4rb1e.utils.argparse.actions.KeyValueAction (with package export) live on branch feature/19 with spec-compliant commit granularity (production code before tests, module boundaries separate); unit test suites for both pass via tox; develop working tree is clean of these files.
I don't have a real use for KMP at the moment. I'm putting it on hold but
leaning towards cancelling the feature completely as I'm not trying to create a
collection of algorithms... My utilities should only contain what I really
need...
I'd like to be able to track when an issue is not being used, in addition to
when I'm not actively working on issues. Therefore I introduced `cancelled` and
`hold` status.
