[Phase 16] S8 — Run-scoped effective state and provenance
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 12/100
- Tipo de issue
- Error
- Claridad
- Necesita aclaración
- Estado de actividad
- Activo
- Stack tecnológico
- huggingface, python
Línea de trabajo
Start with the step plan in docs/roadmap/phase-16-trust-surface-hardening.md (lines 518-551) and the ForgeTrainer run state, then trace how the model card and compliance manifest producers read the config today. The fit-check YAML emitter and the --compliance-export path without a training run are the other entry points. Done means the six exit criteria pass, including the 4x2 lora.method and CUDA matrix and the A-to-B and B-to-A run isolation test. This is cross-cutting design work spanning several units, so it should be split before anyone starts.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Roadmap · Phase 16, step S8 · size XL · 4 unit(s) · planned in
docs/roadmap/phase-16-trust-surface-hardening.md:518-551
Summary
Artifact producers and estimators re-interpret the original config instead of consuming this run's observed effective state, and the provenance that does exist is bound to a module singleton instead of the run. The model card misses DoRA, PiSSA and rsLoRA in all three of its surfaces, and the manifest's training_parameters.dora is False for method: dora, contradicting the same manifest's adapter_method — an internally inconsistent compliance artefact.
Units
| Unit | Tracked by (October 2026 review) |
|---|---|
C31-RUN-OUTCOME (= CORE-06 + CORE-07 + CORE-12) |
#569 · #572 · #647 · #700 · #804 |
F-W20260729-CORE-09 |
#503 · #561 |
F-W20260729-TRUST-08 |
#569 · #647 · #686 · #689 · #709 |
F-W20260729-OPS-22 |
— no review issue; tracked by this issue |
Decisions this step executes
- C-6 — keep
model_lineage.quantizationmeaning "requested" and addquantization_effectivebeside it. - C-7 — effective fields when no training run occurred: a
"not_observed"sentinel. - C-9 —
training.gradient_checkpointingdoes not become a real field; delete fit-check's invalid recommendation.
Plan
- Record the run's effective state in
ForgeTrainerand pass it to the card and manifest producers as a parameter — do not addCARD→MODELorCOMPLIANCE→MODELimport edges (architecture.md has none). forgelm --compliance-exportwithout a training run writes the"not_observed"sentinel.- No fixture mass-regeneration: each regenerated golden fixture needs a named reason.
Exit criteria
- A 4×2 matrix (
lora.method× CUDA available/absent,load_in_4bit) proves the card and the manifest name the method and quantization actually applied, with the requested value kept in its own field. - Runs A→B and B→A in one process produce manifests with no cross-contamination.
- A failed
merge_and_unload()is visible identically in the audit log, the card and the manifest. - Every YAML snippet fit-check emits validates against
ForgeConfig. - A directory fingerprint changes on content change and not on traversal order.
- A test enumerates all loader surfaces, so a new one cannot be added silently.
How to deliver
- One root-cause family, committed on its own; then an Opus review round and a Sonnet review round, each with verified findings fixed and committed before the next step begins.
- A reproducer that is red before the fix and green after; the full gauntlet from
CLAUDE.mdpasses under./.venv/bin/python. - Every English documentation edit ships with its Turkish mirror in the same commit; a new or renamed audit event gets its EN and TR catalog rows in the same PR.
- A step that grows a deferred module carries its
budget_historyjustification in the same diff; a widened guard rolls out non-strict first, then flips. - Commit bodies cite
Absorbs F-W20260729-…; the CHANGELOG[Unreleased]section gets an entry only for a change a user or library consumer can observe (decision C-20).
Planned in docs/roadmap/phase-16-trust-surface-hardening.md (read at f94595f). Unit IDs (F-W20260729-…) come from the 2026-07-29/30 full-project review; the issue numbers next to them are the October 2026 review's records of the same defects.
- Lenguaje dominante
- Python
- Estrellas
- 9
- Forks
- 1
- Merge medio
- 7 h 42 min
- PR fusionados (30 d)
- 4
Preparar el entorno
- Incluye un Dockerfile o un archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de HodeTech/ForgeLM
-
area: dev-tooling bug severity: low source: roadmap wave: 4
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
-
area: site bug good first issue severity: low source: review-2026-09 wave: 4
Dificultad 2/5 1-3 horas Aptitud para principiantes 66/100
-
documentation good first issue severity: medium source: review-2026-09 wave: 3
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
-
documentation good first issue severity: low source: review-2026-09 wave: 4
Dificultad 1/5 1-3 horas Aptitud para principiantes 80/100
-
documentation severity: medium source: review-2026-09 wave: 3
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Todos los issues de HodeTech/ForgeLM
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
-
good first issue No-AI
Dificultad 2/5 1-3 horas Aptitud para principiantes 69/100
-
documentation
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
-
🐛 Bug: Calendar work items cannot be opened on mobilePosiblemente ocupada Un pull request vinculado a esta issue está abierto o ya se fusionó. Abierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 75/100
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 2 días