Coding and Analysis Workflow

Prepare the task and safe workspace

State the expected behavior or analytical question, relevant files or fields, constraints, acceptance tests, and what must not change. Inspect the actual code, schema, and data before proposing a solution.

Use a branch, copy, sandbox, or read-only data source appropriate to the risk. Remove secrets and unnecessary personal data; never paste production credentials or unrestricted datasets into a prompt.

Coding or analysis work order

text

Outcome/question: [BEHAVIOR OR DECISION]
Inputs: [FILES, SCHEMA, DATA SAMPLE]
Constraints: [SCOPE, PERFORMANCE, PRIVACY]
Do not change: [INVARIANTS]
Checks: [TESTS, QUERIES, RECONCILIATION]
Workspace: [BRANCH, SANDBOX, READ-ONLY]
Rollback: [HOW TO RESTORE]

Execute small, inspectable increments

Ask for or create a short plan, then change one coherent behavior at a time. Review diffs, queries, assumptions, and intermediate results before expanding scope.

For analysis, preserve raw inputs and make transformations explicit. For code, prefer existing project patterns and avoid unrequested dependencies, permissions, or architecture changes.

Verify with the system, not the explanation

Run the relevant formatter, type checks, unit tests, integration tests, and production build. Exercise the changed behavior and important failure paths. A model's explanation is not evidence that code compiles or works.

For analysis, validate types, missingness, units, row counts, joins, filters, outliers, and reconciliation totals. Review whether the sample represents the population and whether the conclusion exceeds the data.

Recover without destroying evidence

When a check fails, preserve the error and smallest reproduction, identify whether the cause is code, data, environment, or expectation, and correct the narrowest layer. Do not delete tests or weaken assertions merely to obtain green output.

Use version control or a verified backup to reverse unsafe changes. Stop before destructive, external, costly, or permission-expanding actions unless the authorized workflow explicitly allows them.

Review security, privacy, and downstream impact

Inspect authentication, authorization, secrets, input validation, logs, dependencies, data exposure, and failure behavior. Generated code can be syntactically valid while introducing insecure or biased behavior.

Record the task, diff or query, tests, data-quality results, reviewer, deployment boundary, and rollback evidence. Commit only the verified scoped change.

Practice activity

Complete a reversible coding or analysis change

Choose a low-risk code defect or small dataset question and write the work order with invariants, checks, workspace, data policy, and rollback.
Implement one coherent change or transformation while preserving a diff or query log.
Run at least three relevant checks, including one failure or boundary case.
Inject or identify one failure, preserve its evidence, recover narrowly, and confirm the original checks still pass.

What to produce

A work order, diff or query, and check output tied to the acceptance criteria.
A failure-and-recovery record containing reproduction, cause, correction, regression check, and rollback path.

Reflect before continuing

Which result looked correct until you checked the real code, data, or failure path?

You will be able to

Prepare the task and safe workspace

Execute small, inspectable increments

Verify with the system, not the explanation

Recover without destroying evidence

Review security, privacy, and downstream impact

Complete a reversible coding or analysis change

What to produce

Reflect before continuing

Sources and verification

Make it stick.