refactor: remove hardcoded CATEGORY_NAMES and move consumer utilities out of generic client #3

New Issue

forbes · 2026-02-16T15:54:16Z

forbes commented

2026-02-16 15:54:16 +00:00

Problem

The client hardcodes 170 Kindred-specific category codes in CATEGORY_NAMES (lines 76-232 of silo_client/__init__.py). This violates the server's core philosophy of schemas as configuration, not code (SPECIFICATION.md §1.1).

Categories are defined in YAML on the server and served dynamically via:

GET /api/schemas -- list all schemas
GET /api/schemas/{name} -- get schema with all segments and enum values
POST/PUT/DELETE on /api/schemas/{name}/segments/{segment}/values/{code} -- CRUD enum values at runtime

Consequences

If anyone adds/renames/removes a category on the server, the client is immediately stale
Other Silo deployments with different schemas (e.g. the simple sequential schema) get wrong categories
The helper functions assume CCC-NNNN format, breaking for other schema formats

Proposed Changes

Delete CATEGORY_NAMES dict entirely from silo_client/__init__.py
Move these utilities to consumer repos (silo-mod, silo-calc):
- sanitize_filename() -- filesystem concern, not API concern
- parse_part_number() -- assumes CCC-NNNN format specific to kindred-rd schema
- get_category_folder_name() -- filesystem path construction
Add list_schemas() method so consumers can fetch categories from the server dynamically (see schema endpoints issue)

Rationale

The README describes this as a shared Python HTTP client for the Silo REST API. A generic HTTP client should not embed domain-specific part numbering knowledge. Consumers that need category names should fetch them from the server via the schema API.

## Problem The client hardcodes 170 Kindred-specific category codes in `CATEGORY_NAMES` (lines 76-232 of `silo_client/__init__.py`). This violates the server's core philosophy of **schemas as configuration, not code** (SPECIFICATION.md §1.1). Categories are defined in YAML on the server and served dynamically via: - `GET /api/schemas` -- list all schemas - `GET /api/schemas/{name}` -- get schema with all segments and enum values - `POST/PUT/DELETE` on `/api/schemas/{name}/segments/{segment}/values/{code}` -- CRUD enum values at runtime ### Consequences - If anyone adds/renames/removes a category on the server, the client is immediately stale - Other Silo deployments with different schemas (e.g. the `simple` sequential schema) get wrong categories - The helper functions assume `CCC-NNNN` format, breaking for other schema formats ## Proposed Changes 1. **Delete `CATEGORY_NAMES` dict** entirely from `silo_client/__init__.py` 2. **Move these utilities to consumer repos** (silo-mod, silo-calc): - `sanitize_filename()` -- filesystem concern, not API concern - `parse_part_number()` -- assumes `CCC-NNNN` format specific to `kindred-rd` schema - `get_category_folder_name()` -- filesystem path construction 3. **Add `list_schemas()` method** so consumers can fetch categories from the server dynamically (see schema endpoints issue) ## Rationale The README describes this as a shared Python HTTP client for the Silo REST API. A generic HTTP client should not embed domain-specific part numbering knowledge. Consumers that need category names should fetch them from the server via the schema API.

forbes referenced this issue

2026-02-16 15:54:36 +00:00

feat: add missing schema API methods (list_schemas, get_schema_form, enum value CRUD) #4

forbes referenced this issue from a commit

2026-02-16 17:23:50 +00:00

refactor: remove hardcoded CATEGORY_NAMES, add missing schema API methods

forbes referenced a pull request that will close this issue

2026-02-16 17:24:07 +00:00

refactor: remove hardcoded CATEGORY_NAMES, add missing schema API methods #14

forbes closed this issue

2026-02-16 17:24:50 +00:00

Sign in to join this conversation.