Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

[Phase 16] S8 — Run-scoped effective state and provenance

未关闭
  • 哪里不对？
#894 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
12/100
Issue 类型
缺陷
描述清晰度
需要澄清
活跃度
活跃
技术栈
huggingface, python
领域
documentation, machine-learning

调研方向

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.

由索引模型根据 Issue 内容生成。

描述

phase: 16 source: roadmap

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.quantization meaning "requested" and add quantization_effective beside it.
  • C-7 — effective fields when no training run occurred: a "not_observed" sentinel.
  • C-9 — training.gradient_checkpointing does not become a real field; delete fit-check's invalid recommendation.

Plan

  • Record the run's effective state in ForgeTrainer and pass it to the card and manifest producers as a parameter — do not add CARD→MODEL or COMPLIANCE→MODEL import edges (architecture.md has none).
  • forgelm --compliance-export without 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.md passes 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_history justification 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.

主要语言
Python
星标
9
派生
1
平均合并
8 小时 10 分钟
30 天内合并 PR
5

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

HodeTech/ForgeLM 的其他 Issue

查看 HodeTech/ForgeLM 的全部 Issue

相似的 Issue

更多 Python Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。