httk.workflow.hygiene

Describing and repairing a project, its remotes, and its workspace.

Everything here answers an operator question about state that already exists: what is this project, what is this remote configured to do, what is wrong with this project and can it be fixed. Nothing here is on the execution path of a job, and every repair is explicit — project_doctor() reports by default and only changes something when it is asked to.

Attributes

Classes

Finding

One thing the doctor looked at, and what it found.

Functions

describe_project(→ dict[str, object])

Describe one project: its metadata, its keys, its workspace, its manifest.

workflow_show_section(...)

Contribute the workflow rows of httk project show.

describe_remote(→ dict[str, object])

Describe one remote: where it lives, what it is, how it is configured.

remove_remote(→ dict[str, object])

Remove one remote bundle, refusing while a transfer still needs it.

project_doctor(→ dict[str, object])

Check one project for the conditions that quietly break it later.

Module Contents

httk.workflow.hygiene.PROJECT_DESCRIPTION_FORMAT = 'httk-project-description'[source]
httk.workflow.hygiene.REMOTE_DESCRIPTION_FORMAT = 'httk-remote-description'[source]
httk.workflow.hygiene.DOCTOR_REPORT_FORMAT = 'httk-project-doctor'[source]
httk.workflow.hygiene.DOCTOR_FRAME_FORMAT = 'httk-workflow-doctor'[source]
httk.workflow.hygiene.TMP_MAXIMUM_AGE_SECONDS = 86400[source]
httk.workflow.hygiene.describe_project(project_root: str | os.PathLike[str] | None = None, *, verify: bool = True) dict[str, object][source]

Describe one project: its metadata, its keys, its workspace, its manifest.

verify walks the tree to classify the manifest, which is what makes the description say whether the project is currently described by what it signed; by design, pass False for a cheap answer when verification is not required, because that skips the tree walk.

httk.workflow.hygiene.workflow_show_section(project: pathlib.Path, *, verify: bool) httk.core.project.cli.ProjectShowSection[source]

Contribute the workflow rows of httk project show.

This is the workflow half of what describe_project() reports — the workspace, the manifest, and the remotes — registered into the umbrella httk project command as a show section. The anchor half (metadata and keys) is rendered by httk-core; here we only add what a workflow installation knows about a project.

httk.workflow.hygiene.describe_remote(name: str, *, project: str | os.PathLike[str] | None = None) dict[str, object][source]

Describe one remote: where it lives, what it is, how it is configured.

Credential values never appear. A queue’s settings are reported with the file each one came from, and for a setting stored in the manifest-excluded credentials.json only its name is reported: a description an operator can paste into a bug report must never carry a password.

httk.workflow.hygiene.remove_remote(name: str, *, project: str | os.PathLike[str] | None = None) dict[str, object][source]

Remove one remote bundle, refusing while a transfer still needs it.

A sealed bundle that has not been acknowledged is work this remote still owes an answer about, and the adapter is how that answer is fetched. Removing the remote would leave the transfer with no way home, so it is refused by name — retire or fetch the transfer first.

class httk.workflow.hygiene.Finding[source]

One thing the doctor looked at, and what it found.

check: str[source]
status: str[source]
message: str[source]
repairable: bool = False[source]
repaired: bool = False[source]
action: str | None = None[source]
details: dict[str, object][source]
as_mapping() dict[str, object][source]

Return the JSON representation of this finding.

httk.workflow.hygiene.project_doctor(project_root: str | os.PathLike[str] | None = None, *, repair: bool = False) dict[str, object][source]

Check one project for the conditions that quietly break it later.

Every check reports; a check that can be fixed automatically is fixed only when repair is asked for, and a run that repaired anything says exactly what it did — in the log and, when the project has a workspace, in that workspace’s journal, so the repair is part of its durable history.