Skip to content

Repository identity migration — rename, or replace with a clean repository

Status: Path B executed 2026-08-08 — non-destructively.

TaylorAmarelTech/duecare now exists and holds the full 1,732-commit history. gemma4_comp was not renamed, archived, deprecated, or modified in any way: it remains the live public repository that the frozen Kaggle writeup points judges at, and it stays that way until grading is confirmed complete. Nothing in the sections below about archiving or link cutover has been done.

Execution receipt (2026-08-08)

Step Result
New repository TaylorAmarelTech/duecare, private, created 2026-08-08
History pushed master + ui-polish-2026-05-23, explicit refspecs only
Refs on the new remote exactly 2 — no refs/backup/*, no refs/pull/*
Fresh-clone verification 1,732 commits; git fetch 'refs/pull/*' returns 0 refs
Credential scan of the clone 0 usable credentials; only the runbook's truncated 12- and 11-character revocation-table prefixes (real keys are 39 and 37 characters)
Nomenclature pass 223 files, 553 replacements
Provenance preserved /pull/, /actions/runs/, and /commit/ URLs in 4 files still resolve against gemma4_comp, where those pull requests and runs actually exist
Untouched by design _archive/**, SECURITY.md, docs/security/** — historical records that would be falsified by rewriting
Gates all six validators PASS; suite matches master exactly (8 pre-existing local-environment failures, identical before and after — see below)

The refs/pull/* residue described in security/CREDENTIAL_HISTORY_PURGE.md does not exist in duecare — it starts clean by construction. That residue remains in gemma4_comp and is still inert, because both credentials were revoked at their providers on 2026-08-05.

Known, pre-existing, not caused by this migration: a full local pytest packages tests run reports 8 failures on duecare and on untouched gemma4_comp master. They pass in isolation. At least test_run_fails_cleanly_without_auth fails because this workstation has Kaggle credentials configured while the test asserts their absence. CI is green because GitHub Actions has no such credentials. These are environment artifacts, not defects, and they are not a migration regression.

Publication (2026-08-08, owner-requested)

  • duecare made public;
  • GitHub Pages enabled with build_type=workflow; the MkDocs deploy succeeded and https://tayloramareltech.github.io/duecare/ serves the documentation, deep pages included. The previously failing "Deploy docs site" run had failed only because Pages was not yet enabled.

gemma4_comp and its Pages site were not altered and both still return 200.

Duplicate scheduled workflows — one item still open

The new repository inherited three cron schedules. All three are read-only (none commits back), so there is no divergence risk, but until gemma4_comp is archived both repositories will run them, doubling outbound requests to third-party NGO and government sites.

Workflow Schedule State on duecare
scheduled-scrape daily 06:17 UTC disabled 2026-08-08
entity-harvest Mondays 05:23 UTC still active — see below
sentinel-weekly Mondays 09:00 UTC still active — see below

GitHub registers a workflow only after its first run, so the two weekly jobs could not be disabled pre-emptively — the API returns 404 for an unregistered workflow even though the file is present on the default branch. They will register when they first fire on a Monday. Disable them then:

gh workflow disable entity-harvest.yml  --repo TaylorAmarelTech/duecare
gh workflow disable sentinel-weekly.yml --repo TaylorAmarelTech/duecare

Do not "fix" this by editing the workflow files, which would fork the two repositories' CI configuration for a temporary condition. Archiving gemma4_comp disables its workflows automatically, at which point re-enable all three on duecare with gh workflow enable.

Repository hardening applied at publication

  • secret scanning and push protection enabled on duecare (both were off by default on the new repository — the same gap that let the original credential exposure sit unnoticed for three months);
  • topics set for discovery, carrying forward the original set minus hackathon, which described the artifact rather than the project;
  • description, MIT licence, and duecare-ai.com homepage confirmed.

Hugging Face: no card exists to update

TaylorScottAmarel/duecare-gemma-4-e4b-safetyjudge is public but empty — .gitattributes only, no README, no weights, 0 downloads. It is a reserved placeholder, consistent with the model registry recording every entry as planned. There is no model card pointing anywhere, so there is nothing to re-point. If a model is ever published there, its card should cite duecare and reuse MODEL_CARD_DRAFT.md, which documents the adapters published in the Kaggle learning-study dataset, not on Hugging Face.

Archiving gemma4_comp — cancelled by owner decision (2026-08-08)

The runbook below recommended archiving the old repository behind a pointer README. That step is not being taken. The owner's decision is to keep gemma4_comp online, public, and available indefinitely, with a signpost in its README directing readers here.

This is the better outcome, and it removes the risk the runbook was hedging against rather than merely deferring it:

  • the frozen Kaggle writeup link keeps resolving to a live, non-archived repository, with no "Archived" banner for a reviewer to misread;
  • every commit SHA, permalink, and documentation link ever shared stays valid;
  • the Kaggle kernels install from gemma4_comp and keep working untouched, so no judged artifact has to be re-pushed and re-run;
  • tayloramareltech.github.io/gemma4_comp/ stays published, so the question of whether archiving would have unpublished it never has to be answered.

The signpost landed in gemma4_comp's README on 2026-08-08. It is worded to route readers rather than to deprecate: submission verifiers stay there, code reusers come here, Kaggle users change nothing.

Consequence for this repository: duecare is the development line, not a replacement that requires anything to be shut down. Both remain live. Nothing in this document authorizes archiving, deleting, or redirecting gemma4_comp.

Optional, no longer required

  • re-pushing the 3 active Kaggle kernels to install from duecare. Their current gemma4_comp source is permanent, so this buys consistency only. It edits a judged artifact and triggers a re-run, so it is worth doing — if at all — well after grading, not during it.

Original planning document follows. It was written before execution and is retained because its cost analysis is what justified choosing Path B.

This document is gated on the same event as POST_COMPETITION_HOSTING_TRANSITION.md: the owner confirming that Gemma 4 Good grading is complete. It covers a different concern — the identity and history of the source repository, not where the website is hosted.

Why anyone would want this

Two goals get bundled together in the phrase "clean repo with a new name." They are separable, they have different costs, and only one of them is actually pressing.

Goal What it means Solved by
Better name gemma4_comp is a hackathon-artifact name. The product is DueCare. A rename
Clean history Both revoked credentials remain fetchable through GitHub's frozen refs/pull/* refs (see security/CREDENTIAL_HISTORY_PURGE.md) A fresh repository, or a GitHub Support request

A rename does not clean history — the PR refs travel with the repository. A fresh repository does not require a rename, but it is the only way to resolve the refs/pull/* residue without depending on GitHub Support.

The hard constraint: do not touch this before results

The Kaggle writeup was submitted and is frozen. It points judges at github.com/TaylorAmarelTech/gemma4_comp, and the competition awards 30 points for Technical Depth & Execution as verified by the code repository.

  • A 404 at that URL is a direct scoring loss.
  • An Archived banner reads as "abandoned" to a reviewer who does not know the backstory.

Neither is worth trading for tidiness. Both goals below survive waiting.

Measured inventory (2026-08-07)

What actually pins the current name, counted rather than guessed:

Surface Count / state Breaks on a fresh repo?
Tracked files naming gemma4_comp 314 Mechanical sed; most are docs/ and archives
Active Kaggle kernels installing from the repo 3 kernels, 9 refs, via DUECARE_REPO env default Yes — each needs a re-push
Kaggle writeup link Frozen, unchangeable Yes — mitigated by archiving, not deleting
GitHub Pages docs URL tayloramareltech.github.io/gemma4_comp/ — derived from repo name Yes, on either path
Helm repo URL Same Pages host Yes, on either path
CI workflows Use github.repository context; only comments name the repo No — portable as written
PyPI Not published (all three package JSON APIs return 404) No — no immutable external metadata pins the URL
Hugging Face adapter repo Live; model card references the repo Card edit, cheap
Stars / forks / watchers 4 / 0 / 0 4 stars lost; nothing else
Repository size 306 MB (seed_prompts.jsonl alone trips GitHub's 50 MB warning three times) An opportunity — see below

The absence of published PyPI packages is the single most important line in that table. Published package metadata is immutable and would have pinned the old URL forever. It does not exist, so migration is far cheaper than it looks.

Path A — rename in place

gh repo rename duecare --repo TaylorAmarelTech/gemma4_comp
  • GitHub redirects old web and git URLs to the new name, indefinitely, for clone, fetch, and push.
  • Stars, issues, pull requests, and history are preserved.
  • Cost: the Pages URL changes to tayloramareltech.github.io/duecare/. Documentation links and the Helm repo URL must be updated. Redirects for Pages are less dependable than for git.
  • Does not remove the refs/pull/* residue.
  • Risk: if anyone later creates a repository named gemma4_comp under the same account, the redirect breaks permanently.

This is the option that does real work: it produces a repository whose history has never contained the credentials, in any ref, cached or otherwise.

# 1. Create the new repository (private first — verify before exposing).
gh repo create TaylorAmarelTech/duecare --private \
  --description "DueCare — an agentic LLM safety harness for migrant-worker exploitation"

# 2. Push the already-purged history. No PR refs, no cached SHAs come with it.
git remote add duecare https://github.com/TaylorAmarelTech/duecare.git
git push duecare master:master
git push duecare --tags

# 3. Prove it is clean before making it public.
git ls-remote duecare
#    Then, on a fresh clone of the new repo:
#    git fetch origin 'refs/pull/*:refs/remotes/origin/pr/*'   -> returns nothing
#    git log --all -S'<key-prefix>' | wc -l                    -> 0

Then, and only then:

  1. Update the 314 tracked references, the 3 Kaggle kernel DUECARE_REPO defaults, the docs Pages URL, the Helm repo URL, and the HF model card.
  2. Re-push the 3 active Kaggle kernels so their installs resolve.
  3. Make duecare public.
  4. Archive — do not delete — gemma4_comp, with its README replaced by a pointer to the new repository.

Archiving matters: an archived repository stays fully readable and clonable, so the frozen Kaggle writeup link keeps resolving and lands a reader on a clear signpost. Deleting it would break that link permanently, along with every external permalink ever shared.

What Path B also fixes

  • Makes security/GITHUB_SUPPORT_REQUEST.md unnecessary for the new repository — it starts clean by construction. (Send it anyway if the archived repository should also be scrubbed.)
  • Offers a natural moment to move configs/duecare/domains/trafficking/seed_prompts.jsonl (57–63 MB across revisions) to Git LFS or a Kaggle dataset, cutting the 306 MB clone. Do this as a deliberate, separately verified change — not silently during the migration, or the "file content is byte-identical" guarantee from the purge is lost.

Recommendation

Wait for results. Then take Path B, named duecare, archiving the old repository with a pointer README.

Path A is tempting because it is one command, but it buys the cosmetic half of the problem and leaves the substantive half — and it still breaks the Pages URL, which is most of Path B's link work anyway. If the Pages URL must change regardless, take the option that also produces genuinely clean history.

If neither goal feels worth the work after results are in: do nothing. The credentials are revoked, the residue is inert, and a working repository that judges have already visited has real value. "Deprecate and replace" is a preference, not a remediation.

Do not

  • Do not execute any part of this while grading is open.
  • Do not delete gemma4_comp under any circumstance — archive it.
  • Do not rename and create a fresh repository under the old name; that breaks the rename redirect.
  • Do not bundle the LFS/large-file change into the same operation as the identity change.
  • Do not push refs/backup/* to any remote. Those refs hold the original unpurged history.

Acceptance gate

  • competition grading completion is owner-confirmed;
  • the new repository's history is verified clean on a fresh clone, including refs/pull/*;
  • all 3 active Kaggle kernels install and boot from the new URL;
  • the docs Pages site and Helm repo URL resolve at their new addresses;
  • gemma4_comp is archived, readable, and carries a pointer README;
  • python scripts/validate_public_surface.py and python scripts/check_external_links.py --check pass against the new URLs.