# Hcod Result Reporting > Use when HyperCOD/VMamba experiment results are ready and Codex needs to archive train logs, choose or confirm an output root, generate train-log HTML visualizations, identify the best iteration, or collect paper-style metrics. - Skill: `jiangkaiqi2005/hcod-result-reporting` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add jiangkaiqi2005/hcod-result-reporting` - Raw SKILL.md: https://api.skillmd.com/api/skills/jiangkaiqi2005/hcod-result-reporting/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Web & Frontend - Author: jiangkaiqi2005 (https://skillmd.com/u/jiangkaiqi2005) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/jiangkaiqi2005/hcod-result-reporting --- # HCOD Result Reporting ## Overview Archive a finished HyperCOD experiment into a clear outputs folder, produce a compact report, and verify which checkpoint should be treated as best. The core rule is to classify the experiment family before naming folders; never dump method-family results into the baseline bucket just because paths look similar. ## Workflow 1. Locate the source run directory and artifacts. - Find `train.nohup.log`, config, checkpoints, existing `paper_metrics*`, and any previous HTML reports. - Read project notes when version semantics are unclear: `CHANGELOG.md`, `version_modules.md`, run-local notes, and nearby configs. 2. Choose the output family name before creating files. - Inspect existing directories under the user-specified output root when one is provided. `E:\ViM\outputs` is only an example of a possible root, not a default. - Use the method family, not the implementation shortcut. Examples: - Basic/baseline experiments: `hcod_hsi_basic_cache_160k/` - HSC-SAM imitation experiments: `hcod_hsc_sam_cache_160k/` - RGB/spectral experiments: follow existing `hcod_rgb_*` naming. - If unsure whether a run is baseline, HSC-SAM imitation, ablation, or another family, infer from run notes/configs first; ask the user only if local evidence is ambiguous. - Keep child folders versioned and descriptive, for example `hcod_hsc_sam_v0.1_cache_160k`. 3. Create or use the destination. - If the user did not specify an output root, ask where to put the results before creating or copying files. Do not assume `E:\ViM\outputs`. - If the user specifies `E:\ViM\outputs` or another existing convention, prefer that real path when mounted or accessible. - If the requested drive is unavailable, create a same-structure local mirror under the repo only as a fallback, such as `outputs//`, and clearly say it is not the requested root. - Copy `train.nohup.log` into the destination. Do not copy unrelated run notes whose labels conflict with the method family. 4. Parse the training log. - Extract train points from `Iter(train)` lines: iter, loss, decode/aux losses, accuracy, lr, time. - Extract validation points from `Iter(val)` summary lines: iter, `aAcc`, `mIoU`, `mAcc`, `mDice`, timing. - Associate validation rows with the immediately preceding checkpoint save when the val line does not include the iter. 5. Pick the best iteration. - Default rule: highest validation `mIoU`; break ties by `mDice`, then `aAcc`. - If the user names a different primary metric, use that and state the rule. - Compare the best point with the latest point. Mention when training loss improves but validation quality regresses. 6. Generate the HTML visualization. - Match the style of the closest existing report when the user provides one; otherwise create a self-contained HTML file that opens directly. - Include summary cards, training loss curves, validation metric curves, validation table, best-iter conclusion, paper metrics, and the reproduce command. - Avoid external CDN dependencies unless the existing report already requires them. 7. Establish paper-style metrics for the selected iter. - Prefer running the project tool: ```bash CUDA_VISIBLE_DEVICES= python segmentation/tools/evaluate_hcod_paper_metrics.py \ \ --split test \ --with-flops \ --out-dir /paper_metrics_iter ``` - Save `summary_paper_metrics.json`, `summary_paper_metrics.csv`, `per_image_paper_metrics.csv`, and `metrics_command.txt`. - If the command fails, debug the root cause. If valid metrics already exist from the same config/checkpoint, copying them is acceptable only with an explicit note in `metrics_command.txt` and the final response. - Remove failed-run debris such as timestamped work dirs that only contain failed configs/logs. 8. Verify before reporting completion. - Confirm expected files exist and are non-empty. - Re-read the validation CSV/JSON and recompute best iter. - Confirm the HTML contains embedded data, the best iter, and chart elements. - Scan the destination for stale/wrong family names. - State anything that could not be verified, such as unavailable `E:` mount or missing browser tooling. ## Required Outputs - `train.nohup.log` - `train_log_visualization_.html` - `validation_summary_.csv` - `best_iter_analysis_.md` - `paper_metrics_iter/summary_paper_metrics.json` - `paper_metrics_iter/summary_paper_metrics.csv` - `paper_metrics_iter/per_image_paper_metrics.csv` - `paper_metrics_iter/metrics_command.txt` ## Common Mistakes - Do not assume `hcod_hsi_basic_cache_160k` is correct just because the source work dir contains HSI/cache/160k. That folder is for baseline/basic runs. - Do not assume the output root. If the user did not name one, ask first. - Do not say files were downloaded to the requested root when only a local mirror was created. - Do not pick the final checkpoint as best without checking validation metrics. - Do not hide paper-metrics failures. Record the exact failure and whether metrics were copied from an existing successful run. - Do not leave wrong-name temporary outputs after the user confirms they downloaded the mirror; remove the local mirror when asked.