← registerm/FIND-002.html
On file
Find papers worth reproducing (GitHub-only pass)
Fills REPRO-002 and everything after it.
What it found
6candidates
On hand

Nothing.

Environmentnot recorded

This is the environment file as it stands today, not a record of this run. The run predates environment capture, so what it actually had on hand was never recorded and cannot be recovered.

Name
night-shift-map
Network access
Custom
Allowed domains
arxiv.org www.nature.com www.science.org pmc.ncbi.nlm.nih.gov journals.aps.org www.nber.org openreview.net cacm.acm.org blog.google research.google deepmind.google
Setup script
no setup script
Environment variables
no variables
Brief88 lines
# Find brief — papers worth reproducing

Paste this whole thing. Nothing to fill in.

**Environment:** `night-shift-map`. The exact settings are on this mission's
page — the env file is the only place they live.

---

## The job

Find candidate papers worth reproducing. A good candidate has a replication
package that is public, complete, and actually runnable, and a result worth
checking.

For each candidate: the paper, where its replication package lives, what
language the code is in, roughly how large it is, and why it is worth checking.
Say plainly which ones you could not verify are complete — an unverified
package is a finding, not a gap to paper over.

Do not pad the list. Six real candidates beat twelve with six invented.

## Output — two files, and both are required

**1. `output.md`** — the prose. Write it for a reader. Structure it however
reads best, and end with a section called **Notes on this run**: what you
searched, what failed to load, what you are unsure about. Blunt.

**2. `candidates.yaml`** — the same candidates as structured data:

```yaml
candidates_file:
  mission: FIND-002
  source: output.md
  count: <number of entries below>
candidates:
  - id: C01
    title: <short title>
    domain: <field>
    package_url: <where the replication package lives>
    package_read: yes | no        # did you open it?
    language: <R, Python, Stata, …>
    verified_complete: yes | no | could-not-check
```

**`package_read` and `verified_complete` are different questions.** One is a
network fact, the other a judgment about what you found:

- `package_read: no` + `verified_complete: could-not-check` — you never
  reached the package. Nothing here is a statement about its contents.
- `package_read: yes` + `verified_complete: could-not-check` — you opened it
  and still could not tell whether it is complete. That is a finding about
  the package.

Without the first field those two collapse into the same answer, and a
listing URL you never opened reads exactly like one you did. `package_read`
is checkable: an opened page leaves a fetch in this session's transcript,
which you do not write.

It also marks which of the other fields are observed and which are inferred.
With `package_read: no`, `language` and `verified_complete` are guesses from
the paper or a search result, not from the package — say so in the prose
rather than letting the row imply otherwise.

**These must agree.** Every candidate in the prose appears in the YAML and vice
versa. The board counts entries in `candidates.yaml` — it never parses your
prose, because a count derived from headings is a count that can silently be
wrong. If you can only produce one of the two files, produce neither and
deposit a finding explaining why.

## Where to put them

Push a branch to **`night-shift-network/inbox`** with both files inside a
directory named for this mission:

```
FIND-002/output.md
FIND-002/candidates.yaml
```

The directory is what matters. A file at the root of the branch is not a
deposit and will not be collected — it will sit there looking delivered while
nothing has been.

The branch name does not matter and is deliberately not specified: the relay
reads every branch, so whichever branch your session is already on is fine.
Never delete or force-push a branch, yours or anyone else's; cleanup is
maintainer-side only.