Configuration Persistence

These examples and illustrative results are independently authored teaching materials, not measured model results.

Use case

Repeated issue lookups use the same project, and asking for its name every session interrupts work. Persist a stable nonsecret preference in .config/issue-helper.json relative to the current repository root. The teaching file is {“schema_version”:1,”project”:”team-a”}. Existing login supplies credentials; this file does not store them.

Mechanism

Read and parse JSON, then check schema_version, project and repository applicability. Reuse complete applicable values. Ask only for missing fields; report damaged JSON, unsupported versions or an inapplicable project rather than silently reusing them. Save a newly confirmed nonsecret project choice while keeping authentication in its established channel.

Bad example

Ask for the project name on every team-a issue lookup. Save both the project and access token in issue-helper.json for convenience, and reuse the file in every repository.

Good example

Read .config/issue-helper.json from the current repository root. The teaching format requires schema_version=1 and a nonempty project, such as team-a. Reuse a valid applicable value. Ask only for a missing project. Report damaged JSON, unsupported versions or repository changes and reconfirm applicability. Do not store tokens; use existing login. Saving a project preference does not authorize external writes.

Why the change matters

Persistence turns a repeated preference into readable input; validation prevents old projects, wrong formats or credentials from being carried into another task. Asking only for gaps preserves continuity without treating parseable data as automatically applicable.

Observable expectation

A valid teaching file selects team-a without another question. Removing project asks for that value only; schema_version=2 reports unsupported format; damaged JSON reports a parse failure.

Inspect stored keys for nonsecret configuration only and no copied token. A new repository cannot establish applicability merely from an old file.

Limits

Location, fields and version are teaching conventions; real projects use their established configuration and login mechanisms. Saved preferences may expire and are not standing authorization to create, modify or send issues. The source remains unconfirmed.