Work Log: 2026-04

---

April Close

Theme

April turned the project from result chasing into protocol discipline, while also making the next career direction more explicit.

What Changed

Experiments / Research

• Old Phase 1 results were downgraded to exploratory status after a possible Stage1/Stage2 split mismatch risk was found.
• A clean subject-level split protocol became the formal path.
• Stage1 and Stage2 now need shared outer-split provenance before results can be trusted.
• Multi-seed stability became more important than a single best F1 score.
• P0/P3/P4 became the practical K.I.C.S. paper scope, while P1-P8 and experiment 2 were moved toward later review or journal extension.

Paper / Publication

• The immediate publication target became K.I.C.S. first, then a possible journal extension.
• The paper framing shifted away from only “higher F1” and toward cleaner protocol design, reproducibility, and small-data stability.
• The paper should explain protocol differences from the original CCT-LSTM work instead of pretending to be a strict full reproduction.

Job Preparation / Career Direction

• Job preparation was temporarily reduced to 1 to 2 hours per day until the K.I.C.S. paper is submitted.
• LLM / VLM / agentic-AI projects became a serious direction for aligning research methods with job-market needs.
• LeetCode / ACM preparation became a yearly baseline: reach an exam-passable level before March each year.
• Huawei-style question-bank practice and broader LLM-related knowledge became practical job-preparation material.

Public Site / Blog

• This Jekyll site became a public worklog and resume surface.
• Work Log moved into a dedicated _worklogs collection instead of normal posts.
• The homepage and archive entry point were updated so monthly worklogs can act as a visible project trace.

Project Memory / Documentation

• Project state was moved out of scattered assistant memory and into stable files such as README.md, TODO.md, and run&conclusion.md.
• The public worklog became a lightweight handoff layer, not a place for sensitive result tables or private notes.

Final Decision

• Finish and submit one paper quickly, then use that as the closing point for the current CCT-LSTM stress-estimation direction.
• After the paper, shift more research-method and portfolio work toward LLM / VLM / agentic AI.
• Keep coding-test preparation as a non-negotiable yearly baseline, with March as the target checkpoint.
• Build more practical LLM and hiring-market knowledge, including Huawei-style preparation, to support job searching.

Carry Into May

• Finish the K.I.C.S. paper with P0/P3/P4 as the main scope.
• Verify split metadata before trusting any result row.
• Keep P1-P8 and experiment 2 as follow-up material, not as blockers for the current submission.
• Restart job-preparation intensity after the submission sprint.

---

2026-04-29

Project

Paper writing / experiment monitoring.

Done

• P0/P3/P4 clean runs finished and generated results.
• Paper abstract.
• Paper/Journal writing plan.

  Decision

• The paper should be written for K.I.C.S. first, then extended for a journal.
• K.I.C.S. paper only need P0/P3/P4 results form experiment 1.
• Journal paper can include more protocol variants and experiment 2.

  Risk

• I don’t see any major risk at this point, but the paper writing process can always be more time-consuming than expected.

  Next

• verify split metadata for all runs and results for P0/P3/P4.

---

2026-04-28

Project

Paper preparation / experiment monitoring / job preparation.

Done

• 2/3 seeds of P0/P3/P4 finished and generated results.
• Estimated time of finish: Apr.29th 06:00 JST.
• Estimated f1 between baseline and best method: 0.1x.
• Bought custom domain and set up DNS for this Jekyll site.
• Made an intro animation for the homepage.

  Decision

• Switch job preparation to low, about 1 to 2 hours per day until K.I.C.S. paper is submitted.
• Use the task prediction protocol for the paper, but clearly note the differences from the original CCT-LSTM paper.
• Use the full reproduction for journal submission later, but do not delay the current paper for it.

  Risk

• I forgot all the experiment protocol are for tasks prediction, which means:
  • Does not cover experiment #2 in baseline paper.
  • Won’t be a full reproduction of the original paper.

    Next

• Finish paper’s prior work and method sections.
• Do some ACM coding questions for job prep.

---

2026-04-27

Project

Public worklog site / local Jekyll development / clean p128 experiment queue.

Done

• Installed Docker Desktop and verified docker, docker info, and docker compose were usable locally.
• Turned off unnecessary Docker Desktop features for this workflow.
• Reviewed the practical Docker model for this site:
  • image as the reusable runtime template
  • container as the running instance
  • volume as Docker-managed persistent storage
  • Compose as repeatable service configuration
• Added a Docker Compose Jekyll workflow using the ruby:3.3 image, a mounted project directory, and a Docker volume for bundle dependencies.
• Confirmed why the container listens on 0.0.0.0, while the host port can be bound to 127.0.0.1:4000 for local-only development.
• Moved Work Log out of normal posts and into the _worklogs collection.
• Reframed the old About tab as a Work Log archive entry point.
• Left the personal introduction role to the pinned “Who Am I?” post.
• Added a homepage Work Archive card before pinned posts.
• Polished the Work Archive card toward a cleaner terminal-style surface with dynamic latest-month and entry-count metadata.
• Polished post-card hover behavior and sidebar social links.
• Removed RSS from the lower-left social links and kept GitHub, Twitter, and Email.
• Confirmed the three-seed rPPG Stage1 clean run completed and passed split-metadata checks.
• Resumed the main clean queue; seed 333185252 correctly skipped completed Stage1 work and entered Stage2 P0.

Decision

• Keep Work Log as a public archive collection instead of mixing it into the normal post stream.
• Keep the site development workflow reproducible through Docker Compose rather than depending on host Ruby state.
• Bind local Jekyll preview to localhost for normal development.
• Keep exact experimental scores out of the public worklog unless they are part of a deliberate public result table.
• Treat the current clean p128 queue as the formal path and keep old exploratory results separated.

Risk

Stage2 is now running, but training/results_p128_clean.csv has not been generated yet. Do not treat the clean protocol as result-bearing until Stage2 finishes and writes verified rows.

The public worklog is useful as a resume surface, but it should not leak private notes, unpublished-sensitive tables, or messy job-process details.

Next

• Watch Stage2 P0 for seed 333185252.
• Verify generated result rows and split metadata before using them.
• Let the main queue continue into the remaining clean protocol work.
• Keep the Work Log archive card and sidebar polish in a small visual-change lane.
• Continue appending date-stamped public notes while keeping raw private notes elsewhere.

---

2026-04-26 Late Night to 2026-04-27 Early Morning

Project

Clean queue monitoring / rPPG parallel pretraining / public worklog setup.

Done

• Checked the p128_clean queue progress several times.
• Confirmed seed 333185252 Stage1 landmark completed 7 folds and preserved those checkpoints.
• Found that Stage1 rPPG was much slower than landmark and would delay the full clean queue.
• Updated the main queue script so Stage1 completion and metadata checks are modality-aware.
• Added a parallel Stage1 rPPG script for seeds 333185252, 424505892, and 928861001.
• Added a safer nohup launcher with stop/reset options, pidfile, master log, unbuffered logging, and STOP-file handling.
• Cleanly stopped the previous queue/rPPG jobs, reset only rPPG partial outputs/logs, and kept landmark outputs.
• Started the three-seed parallel rPPG run under nohup.
• Confirmed the parallel rPPG jobs began writing fold outputs, split metadata, and live logs.
• Investigated local history locations for coding-assistant sessions.
• Started converting recent research and engineering notes into this public worklog format.

Decision

• Do not parallelize the full queue because Stage2/results CSV/run-id/partial-dir handling is riskier.
• Parallelize only Stage1 rPPG by seed; this changes scheduling, not the YAML, split, seed, or model protocol.
• Do not attempt fold-level rPPG parallelism unless the training entry point gains explicit fold-range support.
• Use nohup/pidfile/master-log launch for long experiment jobs instead of relying on an interactive terminal.
• Use this blog as a public-facing worklog and resume anchor.
• Keep private or messy thoughts outside this page.
• Use this page for work that is safe to publish and useful to resume later.

Risk

Stage2 has not started yet, and training/results_p128_clean.csv has not been generated. Do not remove the STOP file or restart the main queue until rPPG Stage1 is complete and metadata checks pass.

Note

The purpose of this page is not to create a polished monthly summary. It is mainly a visible trace of what changed, what I decided, what became risky, and what I should do next.

Next

• Let the parallel rPPG Stage1 run finish.
• Verify all rPPG checkpoint split metadata.
• Remove training/STOP_p128_clean and restart the main queue.
• Continue into Stage2 P0/P3/P4 under the clean p128 protocol.
• Continue appending short date-stamped entries.
• Move larger topics into standalone posts when useful.
• Keep private notes in a separate private capture system.

---

2026-04-26 Night

Project

Clean p128 experiment queue.

Done

• Designed the clean p128 protocol.
• Planned P0-P8 under the clean setting.
• Set all relevant embeddings to 128 dimensions.
• Started the first batch of clean p128 runs.

Decision

• The clean p128 queue is the current formal path.
• It should not be mixed with the old exploratory Phase 1 results.

Next

• Continue clean p128 queue.
• Verify checkpoint provenance.
• Compare clean results against old exploratory trends carefully.

---

2026-04-26 Evening

Project

Documentation / handoff.

Done

• Updated README architecture documentation.
• Updated TODO.
• Updated project context files.
• Wrote a cleaner handoff for the clean protocol.

Decision

• Documentation should let future me resume the project without relying on chat history.
• README should stay architecture-level.
• Detailed run status should stay in TODO.md and run&conclusion.md.

Next

• Keep README stable.
• Keep run status in the dashboard and run ledger.

---

2026-04-26 Afternoon

Project

Clean subject-split protocol.

Done

• Implemented the clean subject-split protocol.
• Required Stage1 and Stage2 to use the same outer split.
• Added split-provenance metadata to checkpoints.
• Added verification around saved split information.

Decision

• Reproducibility requires data-split provenance, not just same code and same seed.
• New formal runs should use the clean protocol.

Next

• Verify split metadata for new checkpoints.
• Restart experiments under the clean protocol.

---

2026-04-25 Night to 2026-04-26 Morning

Project

Critical protocol issue.

Done

• Found a potential Stage1/Stage2 split mismatch risk in the old Phase 1 protocol.
• Stopped the old experiment path.
• Downgraded old Phase 1 results to exploratory status.

Risk

A small split-protocol mismatch can invalidate a large amount of experimental work.

This is the kind of issue that is easy to miss when the project evolves over time.

Decision

• Do not keep polishing the old result.
• Rebuild the clean protocol.
• Mark old Phase 1 results as exploratory.

Next

• Implement a clean subject-split protocol.
• Make Stage1 and Stage2 share the same outer split.
• Save split provenance with checkpoints.

---

2026-04-25

Project

Repository cleanup / documentation roles.

Done

• Reorganized git, .gitignore, and resource directories.
• Clarified the roles of several project files:
  • README.md: public-facing project overview and architecture
  • TODO.md: current work dashboard
  • run&conclusion.md: experiment ledger and conclusions

Decision

• README should explain the project to a future reader.
• Temporary notes and current state should not be dumped into README.
• Current state belongs in TODO.md.
• Experiment history belongs in run&conclusion.md.

Next

• Keep README stable and readable.
• Move temporary notes elsewhere.

---

2026-04-24 Evening

Project

Seed variance / methodology direction.

Done

• Reconfirmed large seed-level variance.
• Reconsidered the paper framing.

Decision

The paper should probably not be framed only as “we got a higher F1.”

A stronger framing may be:

• reliable protocol design for remote stress estimation
• small-data reproducibility
• multi-modal fusion stability
• clean separation between exploratory runs and formal evaluation

Risk

If the paper depends too much on one best score, the claim is weak.

Next

• Design runs that can support a methodology-oriented claim.
• Track variance, not only the best result.

---

2026-04-24

Project

Phase 0.5 / Phase 1 monitoring.

Done

• Monitored Phase 0.5 / Phase 1 experiments.
• Reviewed preliminary R0-style results.
• Checked the effect of scheduler patience.
• Continued evaluating whether 128-dimensional vs 256-dimensional embeddings should be compared under a cleaner protocol.

Observation

Training hyperparameters that look like minor engineering settings can meaningfully change conclusions in small-data deep-learning experiments.

Risk

One run is not decisive.

Next

• Continue comparing protocol variants under cleaner conditions.
• Avoid over-interpreting any single result.

---

2026-04-23

Project

Project context system cleanup.

Done

• Migrated and cleaned up the project context system.
• Reduced overlap between memory files, paper notes, and temporary context.
• Defined a simpler structure:
  • CLAUDE.md: long-term project rules and stable context
  • TODO.md: current dashboard
  • run&conclusion.md: experiment result ledger
  • references/: stable reference facts
  • archive/: old memory and paper-context files

Decision

• TODO.md should be the current dashboard.
• run&conclusion.md should be the experiment ledger.
• Long-term rules and stable project assumptions belong in CLAUDE.md.

Note

Research context is infrastructure. If project memory is scattered, future work becomes slower and less reliable.

Next

• Keep TODO.md short and current.
• Keep run results out of chat memory and inside the run ledger.

---

2026-04-22 to 2026-04-23

Project

Formal experiment protocol alignment.

Done

• Re-reviewed the roles of old run series.
• Checked seed choices, embedding sizes, preprocessing choices, and protocol assumptions.
• Reframed older runs as method-evolution evidence rather than final paper evidence.
• Stopped chasing increasingly complex CCT tuning.
• Shifted priority toward cleaner comparisons.

Decision

• Old exploratory runs can remain useful, but they should not become headline paper results.
• Cleaner protocol comparison is more important than more tuning.
• Prioritize reproducibility before optimization.

Risk

If exploratory and formal runs are mixed together, the final paper story becomes hard to defend.

Next

• Keep old runs as exploratory evidence.
• Run cleaner protocol comparisons.
• Separate formal evaluation from method-development history.

---

2026-04-17 to 2026-04-18

Project

Debugging story / portfolio writing.

Done

• Tried drafting a blog-style debugging story around a difficult fold-level issue.
• Considered an audience of programmers, researchers, and potential interviewers.
• Moved the draft out of the research repo and kept it ignored from git.

Decision

• Do not publish the debugging story yet.
• Wait until the experiment protocol and causal chain are cleaner.

Note

A debugging story is only useful if the causal chain is clear. Otherwise, it becomes a diary rather than a technical note.

Next

• Keep raw writing outside the research repo.
• Turn debugging stories into posts only after the technical conclusion is stable.

---

2026-04-16 to 2026-04-17

Project

EDA branch integration.

Done

• Started implementing the EDA branch.
• Decided to represent EDA as window-level physiological features rather than forcing it into the same representation format as video-derived features.
• Worked through environment issues around .venv, uv run, PyTorch, NeuroKit2, and dependency consistency.

Observation

The tri-modal version with EDA produced a promising preliminary result.

Exact scores are intentionally omitted here.

Risk

Adding EDA is not only a model-design issue. The real risk is alignment:

• EDA windows
• video-derived windows
• labels
• config
• preprocessing assumptions
• fold split

If these are not aligned, the model result becomes hard to trust.

Decision

• Treat modality alignment as a first-class engineering requirement.
• Record modality-specific preprocessing assumptions.

Next

• Keep checking whether EDA windows are exactly aligned with video-derived windows.
• Record EDA extraction and alignment rules in project documentation.

---

2026-04-15

Project

Configuration cleanup.

Done

• Checked whether training parameters were actually controlled by YAML configuration.
• Reviewed possible drift between YAML, CLI arguments, and code defaults.
• Moved more important training settings into config.

Risk

If scheduler, patience, and other training parameters are scattered across YAML, CLI, and hard-coded defaults, experiment provenance becomes fragile.

Decision

• Important training parameters should be visible in YAML.
• Future runs should be reproducible from config files.

Next

• Keep config files aligned with actual training behavior.
• Avoid hidden defaults when running formal experiments.

---

2026-04-04 to 2026-04-07

Project

Seed stability / small-data reproducibility.

Done

• Re-ran several experiment variants with different seeds.
• Observed large seed-level variance.
• Compared the effect of patience settings in the scheduler.

Risk

Single-seed results are not reliable enough for paper-level claims in this project.

A single lucky run can make a method look stronger than it really is. A worse-looking but more stable protocol may be more useful than a high but unstable score.

Decision

• Treat seed variance as part of the experimental problem.
• Avoid cherry-picking the best seed as the main conclusion.
• Consider multi-seed stability as part of the methodology.

Next

• Track variance, not only best F1.
• Keep scheduler settings explicit in config and result records.

---

2026-04-03

Project

CCT-LSTM multi-modal fusion.

Done

• Implemented auxiliary losses for unimodal branches:
  • landmark auxiliary head
  • rPPG auxiliary head
  • fusion classifier as the main head
• Tested the idea that auxiliary supervision may help prevent fusion from suppressing useful unimodal signals.

Observation

The auxiliary-loss version looked more stable than the older baseline in preliminary runs.

Exact scores are intentionally omitted here. This page is a public work log, not the final experiment table.

Decision

• Keep auxiliary loss as a serious candidate for the formal protocol.
• Do not judge it from a single run.

Next

• Re-run with multiple seeds.
• Check whether the improvement is stable across folds and seeds.

---

2026-04-02

Project

CCT-LSTM reproduction / protocol review.

Done

• Reviewed the current state of the CCT-LSTM reproduction.
• Re-checked the original paper’s likely training flow.
• Noted that some previous experiments may not be strict faithful reproductions.
• Started moving run results out of scattered memory/context files into a dedicated run ledger.

Decision

• Treat faithful reproduction and method extension as separate tracks.
• Keep experiment results in an explicit result ledger instead of assistant memory or temporary notes.

Note

The freeze vs no-freeze question matters because it changes both interpretation and compute cost. If the encoders are frozen after unimodal pretraining, the reproduction means something different from initializing them into the multi-modal framework and continuing training.

Next

• Compare freeze vs no-freeze behavior.
• Keep run conclusions in run&conclusion.md.