Design history and rationale.
This document grows with the project. New decisions are appended. Existing decisions are not edited. Superseding decisions reference the one they replace.
Status: Accepted
Context:
se-admin began in the Structural Explainability ecosystem, but its useful
boundary is broader:
it loads repository declarations, profiles, tasks, and checks from data files
and applies deterministic administrative operations across repository families.
The package code should be reusable across repository families.
The local data/ directory in this repository is one instance of that engine
for the SE repository family.
Decision:
se-admin is the reusable administrative engine.
Repository-family-specific declarations belong in the admin repository for that family, including:
data/repos.tomldata/profiles.tomldata/tasks/*.toml- family-specific standards and selectors
The SE repository family may keep SE-specific task declarations in this repo. Other families, such as course repositories, should provide their own task files.
Consequences:
- The Python package must remain independent of hardcoded SE repository names and absolute local paths.
- The
--dataoption is the boundary for selecting a repository family. - Each admin repository owns its own task declarations.
- Task files may name a family-specific source repository, such as
se-adminorstreaming-00-admin. - The engine can be reused without copying SE-specific declarations.
Status: Accepted
Context:
Repositories managed by se-admin, may include SE_MANIFEST.toml files.
Requiring every managed repository to depend directly on se-manifest-schema
would duplicate validation tooling across repositories and add dependencies
to repos that only need to be validated administratively.
se-admin is the family-level administration tool. It performs
cross-repository checks, maintenance, and validation orchestration.
Decision:
se-admin depends on se-manifest-schema and owns administrative
manifest validation across managed repositories.
Managed repositories may include SE_MANIFEST.toml without depending directly
on se-manifest-schema, unless they need manifest validation as part of their
own package behavior.
Consequences:
- Manifest validation has one administrative home.
- Course repositories and SE repositories can use
SE_MANIFEST.tomlconsistently. - Ordinary managed repositories remain lighter.
se-admincan run manifest checks consistently across repository families.- Repositories that define schema semantics or expose manifest-validation
behavior may still depend directly on
se-manifest-schema.