Repository navigation
Commit 7a85fa6
committed
[act.docs.sigma.D7+] the repo's first thirty seconds, and two of the five screenshots were not shippable
A portfolio repo is read by someone who will not clone it, so the front door is
part of the work. Five real captures now sit in docs/screenshots/, hero + a table
with captions that say what is on screen and nothing about how nice it is.
I LOOKED AT THEM BEFORE PUBLISHING, and that is the reason this commit is not
just the agent's output. Two were wrong to ship:
① The proposed hero was a close-up: camera inside the pocket, ligand clipped at
the frame edge, most of the image beige ribbon. It does not say what the app IS.
Re-shot from the app's own ligand focus pulled back 1.75x, so the whole β-barrel
reads with the field well nested inside it, and the Fields shot — the actual
differentiator — is now the hero.
② The Fields capture showed the panel printing "Net charge null · Compute time
null s". That is the defect the physics session fixed an hour ago, visible in the
picture because normalize_meta had started filling absent keys with None and the
renderer had not caught up yet. Publishing it would have advertised a fixed bug
on the front page forever. Re-shot after the fix; those rows are gone.
The captions state chemistry, not adjectives: MW 300.4 with LogP 5.60 flagged red
because the ≤5.0 Lipinski rule actually fires on retinoic acid; 2 HBA / 1 HBD / 19
hydrophobic points auto-derived; the ops console reading a live /admin/snapshot.
README now points at STATUS.md and ROADMAP.md immediately under the hero, with the
deployment answer in the same breath — "is any of this live" is the first question
a reader has and this repo answered it wrongly by accident for weeks.
Also landing: docs/FRONTEND_STATE_AUDIT.md, 453 lines, and its verdict is
unwelcome and correct — ligand-store.ts is SHELFWARE. Zero non-test files import
it; exactly one commit ever touched it; ARCHITECTURE.md says the same thing from
the other side ("reimplemented inline"). Worse, its own heavyAtomsFromMolfile
carries a bug a sibling module found and fixed eleven hours earlier, so adopting
it as-is would REINTRODUCE a paid-for fix. Measured, not asserted: 8 modules hold
a current ligand and 0 read the store; 10 async paths produce a ligand-shaped
result and 7 commit it with no currency check, two of those being multi-second
pyscf calls.
And it caught my own half-fix in flight: 4f3fe20 repaired the import path but
`loadMolecule()` still never clears `this.smilesMolfile`, so picking a PDB
structure after a SMILES paste keeps showing the stale molecule across five
facets. A fix landing on one path of two, again, found by an outside reader
within the hour.
NEXT: clear the sticky field; then decide the store's fate — delete or adopt —
because shelfware with a known bug is worse than no module at all.1 parent 7423a87 commit 7a85fa6
7 files changed
Lines changed: 469 additions & 0 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
2 | 2 | | |
3 | 3 | | |
4 | 4 | | |
| 5 | + | |
| 6 | + | |
| 7 | + | |
| 8 | + | |
| 9 | + | |
| 10 | + | |
| 11 | + | |
5 | 12 | | |
6 | 13 | | |
7 | 14 | | |
| |||
18 | 25 | | |
19 | 26 | | |
20 | 27 | | |
| 28 | + | |
| 29 | + | |
| 30 | + | |
| 31 | + | |
| 32 | + | |
| 33 | + | |
| 34 | + | |
| 35 | + | |
| 36 | + | |
21 | 37 | | |
22 | 38 | | |
23 | 39 | | |
| |||
0 commit comments