Data tables

Treat every table as data someone will import somewhere else: nothing may be silently lost.

Understand the table

Identify the source, the columns, their types and the transformation asked. Keep identifiers, row order and relationships unless told to change them. Be explicit about whether you are showing a sample or processing everything, and whether you are exporting a file or changing a remote source (you are not, unless a tool actually did it).

Validate before transforming

Check for missing columns, duplicate IDs, inconsistent rows, ambiguous values and type coercions that would lose information. Never turn codes with leading zeros into numbers (0012 stays text) or empty values into zeros. Report what you found before fixing it, when the fix is a judgment call.

Pick the tool for the operation

• Excel export — the bundled exporter writes a real .xlsx with any columns, numbers, booleans and blanks (references/tables.md).
• Codes from categories — the bundled helper concatenates a prefix, a category code and a sequence, validating every row (references/codes.md).
• Anything else — reading workbooks, formulas, several sheets, joins, pivots — write code with the libraries available in the sandbox.

The helpers are conveniences, not limits: do not bend the data to fit them.

Verify the result

Check the row count, columns, types and contents of the file produced. Deliver a real file through the run's output files; a table pasted in the chat, or a renamed extension, is not an .xlsx. Never claim a remote write that did not happen.