# ADR-136: Assisted Work Keeps the Author's Voice; Corrections Ship Separately

## Status

Accepted, 2026-08-10.

<!-- RESOLVED 2026-08-10: hkl approved the scaffold default for Decision point 5
     ("scaffold is right"). That was the only item blocking acceptance; the rest was
     already practice, proven on the 2026-08-09/10 run. All five ADR verification
     gates re-run and passed at acceptance. -->

## Status History

```yaml
status_history:
  - date: 2026-08-10
    status: Proposed
    changed_by: hkl
    reason: >
      Generalising the Class XII CS project work into reusable skills surfaced a policy
      with lasting force that no existing ADR governed: what we may and may not do to an
      artefact that will be submitted as someone else's own work.
    changed_via: adr-kit (360lm)
  - date: 2026-08-10
    status: Accepted
    changed_by: hkl
    reason: >
      hkl approved the scaffold-not-generate default for Decision point 5. All five ADR
      verification gates re-run and passed: completeness (5 alternatives, both consequence
      directions), evidence (6 references), clarity (no hedging), consistency (cross-links
      to ADR-134/135, no conflict with any Accepted ADR), revisitability (8 triggers plus
      an explicit non-scope list).
    changed_via: adr-kit (360lm)
```

## Context

360LM increasingly assists with work that is **submitted under someone else's name** — a student's
school project today; by easy extension a junior's PR, a vendor's deliverable, a client's report.
A grep of all 136 ADRs on 2026-08-10 found **nothing governing this**. The absence is the problem:
without a stated rule, "being helpful" silently escalates from review into authorship, and nobody
notices the line being crossed because each individual improvement looks like a kindness.

**The concrete case that forced it.** A Class XII CBSE project (Library Management, Python+MySQL)
was reviewed across two rounds. What made that assistance legitimate was specific and factual:
**the student wrote the program and fixed 15 of her own 16 bugs herself, unprompted.** The
assistance was review — finding, explaining, and evidencing — not writing.

Three concrete pressures pushed the other way during that run, and each had to be resisted
deliberately rather than by instinct:

1. **The submission artefact wanted to carry its own corrections.** A `# FIX:` comment is the
   natural place to explain a change — and it announces to the examiner that someone else worked
   on the file.
2. **A misspelling in the author's own comment** (`neccessary`) was trivially fixable. Fixing it
   silently would have been a small, invisible substitution of our judgement for hers. It was
   **flagged to hkl instead, and corrected only when he asked** — after which the payload check
   moved by exactly one character, proving the edit was only what it claimed to be.
3. **Generalising the work into a skill raised a sharper version:** the skill must also accept a
   *topic only*, with no code. At that point "assist" and "write it for them" become the same
   keystroke unless a line is drawn in advance.

hkl set rules 1 and 2 during the run. This ADR records them, states the reasoning that makes them
more than fussiness, and settles the third case before a skill can drift across it.

## Decision

**When we assist with work that will be submitted as someone else's own, the deliverable artefact
carries no trace of our involvement, and everything we found ships separately.**

Five binding rules:

1. **Zero-trace artefact.** The submitted file contains no `# FIX:`, no "bug", no "TODO", no
   "corrected" — nothing that reveals it was reviewed. Enforced by an **executable gate**
   (`gates/zero_trace_scan.py`), not by care.
2. **Corrections ship as a separate, explicitly-labelled document** ("read, do not submit").
   The author receives everything we found; the examiner receives only their work.
3. **The author's own wording is preserved verbatim.** Improvements to their prose, comments or
   naming are **surfaced, never applied silently**. They choose.
4. **The author gets a fix round.** We report; they correct their own work. This step is not an
   inefficiency to optimise away — **it is the step that makes the assistance legitimate.**
5. **Topic-only input scaffolds; it does not ghost-write.** Given a topic rather than code, we
   produce the **spec** (requirements, schema, enumerated feature list, test checklist) and
   **stubs with docstrings stating what each function must do**. The author implements the bodies.
   If they explicitly want full generation, we **say plainly what that means for authorship and
   record the choice** — we never decide it silently.

**Decision Maker:** hkl.
✅ **Point 5 approved by hkl 2026-08-10** ("scaffold is right"). All five points are binding.

## Implementation Notes

- **Gate:** `~/.claude/skills/student-project-review/gates/zero_trace_scan.py` — exits non-zero on
  any banned word; `debug`/`DEBUG` allowlisted so ordinary Python vocabulary does not fire.
  Validated 2026-08-10 both directions: **CLEAN** on the shipped submission `.py`, **13 occurrences
  flagged** on the review document.
- **Skills:** `student-project-review` (rules 1–5 encoded as procedure P2→P4 and the "two modes"
  section) and `report-into-their-design`.
- **Precedent artefacts:** `D:\projects\yesha-library-project\` — `send/…​.py` (zero-trace
  submission) alongside `CODE_REVIEW_Yesha.md` (the separate review document). The pair is the
  worked example.
- ⚠ Rule 1 must stay a **gate**, not a checklist item. It is absolute, and absolutes that depend on
  remembering get forgotten under deadline.

## Revisit If

**Revisit if:**
- **The work stops being submitted as the author's own.** These rules are calibrated to exactly
  that: an examiner or reviewer will attribute the artefact to a named person. For internal 360LM
  tooling the rules are pure overhead — normal review applies there.
- **The institution's or client's own rules on AI assistance change.** If a school, employer or
  client publishes a disclosure regime, that regime governs and this ADR must be re-fitted to it —
  possibly inverting rule 1 into a *disclosure* requirement rather than a *zero-trace* one.
- **Rule 4 (the author's fix round) starts being skipped for time.** That is the load-bearing rule;
  if practice drifts past it, this ADR is being cited while its basis has gone, and it should be
  re-examined rather than quietly relied upon.
- **Point 5 is overridden toward generation.** If topic-only input is allowed to produce finished
  work, the honest framing changes from "assistance" to "drafting", and the disclosure question in
  rule 5 becomes the primary control rather than a fallback.

**Does NOT govern:**
- **360LM's own code and documents**, where normal review, inline TODOs and direct correction are
  correct and expected.
- **Teaching, explaining or pair-working** — walking someone through why a bug happens is not
  authorship and is not restricted here.
- **The mechanics of building the report** (template reuse, verification gates) — those are
  `report-into-their-design` and carry no authorship implication.
- **Attribution of the assistance itself** between hkl and 360LM. Out of scope.

## Alternatives Considered

- **No rule; judge case by case.** Rejected: this is exactly what produced the pressure to inline a
  `# FIX:` comment. Case-by-case judgement under deadline reliably resolves toward "just fix it",
  and the boundary is invisible once crossed.
- **Inline corrections, clearly commented in the artefact.** Rejected: it is the most *convenient*
  option and the one that most directly defeats the purpose — the examiner reads the comment.
- **Silently apply every improvement we can see, including to their prose.** Rejected: it produces
  a better artefact and a worse outcome. The author learns nothing, and the submitted voice is no
  longer theirs. The `neccessary` case is the concrete instance.
- **Full generation, with a disclosure note.** Rejected **as the default**, retained as an
  explicit, recorded, user-chosen path (rule 5). Making it the default would turn a review skill
  into a ghost-writing tool with a footnote.
- **Decline to assist at all.** Rejected: unnecessary and unhelpful. Review, explanation and
  evidence-gathering are legitimate and valuable; it is *substitution* that is not.

## Consequences

**Positive**
- The boundary is explicit and **machine-enforced**, so it survives deadline pressure and staff
  turnover rather than depending on whoever is at the keyboard.
- The author keeps ownership and actually learns — the student fixed 15 of 16 bugs herself.
- The separate review document is a **better artefact than inline comments**: it can be blunt,
  ordered by severity, and read once rather than discovered piecemeal.
- Generalises cleanly beyond students to junior PRs and vendor deliverables.

**Negative / Trade-offs**
- **Slower.** Rule 4 adds a round-trip that a single pass would avoid. That cost is the point.
- Two artefacts to keep in sync; a stale review document is confusing.
- Rule 3 produces slightly worse prose than we could write. Accepted deliberately.
- Rule 5 will occasionally disappoint someone who wanted a finished project.

**Risks and mitigations**

| Risk | Mitigation |
|---|---|
| The zero-trace scan is skipped | It is a **gate with a non-zero exit**, wired into the skill's P4, not a checklist line |
| A banned word appears legitimately (`debug`) | Allowlist, tested — `debug`/`DEBUG`/`Debugger` do not fire |
| Rule 5 erodes into generation by degrees | The skill must **state the authorship consequence and record the choice**; a silent slide is the failure mode to watch |
| Someone cites this ADR to refuse ordinary internal review | "Does NOT govern" names 360LM's own code explicitly |

## Related Decisions

- **ADR-134** — the first ADR to carry a `Revisit If` section; this one follows that pattern.
- The **WHY rule / mandatory `Revisit If`** (`docs/adr/adr-coding-rules.md`, hkl 2026-08-09) — this
  ADR exists partly *because* of it: the zero-token misreading showed what happens when a rule is
  recorded without the conditions that would invalidate it.
- **ADR-135** — Playwright-first for embedded document reading; the reference-document reading that
  feeds gate G1 uses it.

## References

- `~/.claude/skills/student-project-review/SKILL.md` (rules encoded as P2→P4, "two modes")
- `~/.claude/skills/student-project-review/gates/zero_trace_scan.py` (rule 1, executable)
- `~/.claude/skills/report-into-their-design/SKILL.md`
- `C:\Users\Lenovo\Documents\skills-plans\STUDENT_PROJECT_SKILL_PLAN.md` §3.0b, §3.2, §5
- Memory: `project_yesha_school_project.md` ("Standing rules hkl set for this work"),
  `feedback_adr_why_and_revisit_if.md`, `feedback_dl_toolchain.md` #62/#63
- Worked example: `D:\projects\yesha-library-project\` — `send/…​.py` vs `CODE_REVIEW_Yesha.md`