fix(datasets): a chat attachment IS a Fileshare file - #73
Merged
Conversation
Phase 0 told the agent to never accept a CSV as a chat attachment, because attachments capped at 512 KB and inlined text was cut at 20 000 characters. That stopped being true: a file the customer attaches is uploaded to Fileshare by the client, and the agent receives its `file_key` — the same key an explicit upload returns. Telling the customer to upload a file they already uploaded is now the wrong move, and the old text prescribes exactly that. What remains true is the danger the passage was really about, so it is restated in the form it now takes: a file too big to inline arrives as a key plus a labelled sample, and a row count or total taken from that sample is wrong while being specific enough to be believed. `import_analyze` reads every row.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
Phase 0 of the guided CSV import currently reads:
That was accurate when a chat attachment travelled inline as base64. It no longer is: the client uploads an attached file to the tenant's file service (Shared Drive / Fileshare) and the agent receives its
file_key— the very same keyxentral_fileshare(action='upload')returns. Seexentral/agent-os#147.So the instruction now tells the agent to ask a customer to upload a file they already uploaded, and to refuse the shortest path to the import.
What changes
Phase 0 says both routes end in a
file_keyand that an attached file is already in Fileshare.The hazard the passage was really about is kept, in the shape it takes now: a file too big to inline arrives as a key plus a labelled sample of the first lines, and a row count or sum taken from that sample is wrong while being specific enough to be believed —
import_analyzereads every row for a few KB. That warning is the load-bearing half, so it gets the emphasis rather than being dropped along with the obsolete numbers.Only
skills/xentral-datasets/SKILL.mdphase 0 changes; no other skill makes a claim about attachment caps (grepped).reference/csv-import.mdis unaffected — its token table is aboutrows_bulkoutput, which is unchanged.python scripts/validate_library.py→ OK: 337 library items valid against their schemas. SKILL.md stays at 298 lines, under the 500-line guideline.After merge
Cut a tag and bump
LIBRARY_VERSIONin the backend, so the vendored copy stops prescribing the old route. Until thenbackend/_vendor/skills/still carries the old text — it must not be edited there directly.Noticed, not touched
manifest.json'sskillsarray lists eight skills and omitsxentral-datasets(the repo has nine). The backend loader resolves skills by directory, so this looks inert, but if the customer plugin reads that array the datasets skill would be missing for them. Worth a look by someone who knows whether that array is load-bearing — deliberately left alone here rather than guessed at.