Skip to content

fix(kb): resolve venv Python per-platform in kb-ingest/query/collections (Windows) - #5

Draft
noogalabs wants to merge 1 commit into
mainfrom
fix/windows-kb-venv-path
Draft

noogalabs wants to merge 1 commit into
mainfrom
fix/windows-kb-venv-path

Conversation

@noogalabs

Copy link
Copy Markdown
Owner

What

bus/kb-ingest.sh, bus/kb-query.sh, and bus/kb-collections.sh hardcoded "$VENV_DIR/bin/python3" to invoke mmrag.py. On Windows a Python venv places the interpreter at Scripts/python.exe, not bin/python3, so all three KB operations failed on native Windows (Git Bash). Agents ran, but KB ingest/query/collections broke. Only kb-setup.sh had the Scripts/-vs-bin/ platform detect.

This is the bug a Windows operator reported on 2026-05-14 — it never landed.

Fix

Lift the same detect kb-setup.sh already uses into the three scripts: resolve VENV_PY to Scripts/python on Windows (where the venv has a Scripts/ dir) or bin/python3 on Unix, then invoke "$VENV_PY".

Deliberately a single resolve, not a python3 || python command fallback. kb-setup.sh can use cmd || cmd because it's an idempotent import-check. These scripts run real ingest/query operations — a || fallback would re-execute the entire operation on a legitimate non-zero exit (double POST / double query). Resolving the interpreter path once avoids that.

Scope / safety

  • Unix unchanged: on macOS/Linux -d "$VENV_DIR/Scripts" is false, so VENV_PY = bin/python3 — byte-identical behavior to before.
  • bash -n passes on all three.
  • Live Unix smoke: the edited kb-collections.sh, run against the real framework venv, listed all 7 collections, exit 0.
  • Windows path is logic-verified and mirrors kb-setup.sh's proven detect; I do not have a Windows box to live-run it, so flagging that for the reviewer. The Windows venv layout (Scripts/python.exe) is standard CPython.
  • git diff --stat: 3 files, +27/-3.

Draft pending review.

…ons (Windows)

kb-ingest.sh, kb-query.sh, and kb-collections.sh hardcoded
"$VENV_DIR/bin/python3" for the mmrag.py invocation. On Windows a Python venv
puts the interpreter at Scripts/python.exe, not bin/python3, so all three KB
operations failed on native Windows (Git Bash) — agents ran but KB ingest/query
broke. Only kb-setup.sh had the Scripts/-vs-bin platform detect.

Lift the same detect into the three scripts: resolve VENV_PY to
Scripts/python on Windows (where the venv has Scripts/) or bin/python3 on
Unix, then invoke "$VENV_PY". A deliberate single-resolve, not a
`python3 || python` command fallback — these run real ingest/query operations,
and a `||` fallback would re-execute the whole operation on a legitimate
non-zero exit.

Scope/safety:
- Unix unchanged: on macOS/Linux `-d "$VENV_DIR/Scripts"` is false, so
  VENV_PY = bin/python3 — identical to prior behavior.
- bash -n passes on all three.
- Live Unix smoke: edited kb-collections.sh against the real framework venv
  lists all collections, exit 0.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Pase0Pr0p referenced this pull request in Pase0Pr0p/ascendops Jun 27, 2026
Stack API exposes a Bills resource (GET/POST/PATCH) with full AP fields
(vendor, due date, line items, approval status, GL account). Reporting
API v2 also exposes aged_payables_summary.json and bill_detail.json.

Add: Bill type, BillLineItem, AgedPayablesEntry, ListBillsOptions,
listBills()/getBill()/getAgedPayables() to AppFolioConnector interface,
createBill() write stub (Max-only, to confirm). Update implementation
order to include AP as step 6. Add open question #5 for AP write-gate
tier (not publicly documented — confirm at credential-gen).

Monitoring priority #4 (utility bills, vendor payments on time) is now
addressable once Rob's credentials land, regardless of Plus vs Max tier
(read path confirmed available on Plus+add-on).

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
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.

1 participant