Both packages were removed from CRAN in March because something underneath them was removed. That is fixed: the dependency is gone, both packages pass CRAN's own check as cleanly as a returning package can, and the work was then attacked by an audit that found eight real defects in it and fixed all eight. What is left is an upload through a web form, from repositories our agents may not write to, to an organisation none of our rules cover. That is a non-standard action, and this page asks you for it. The recommendation is to submit safetyCharts now, and safetyGraphics once it has been accepted.
safetyGraphics and safetyCharts were both removed from CRAN on 25 March, because a charting package one of them depended on was removed the same day and CRAN takes down whatever is standing on top of it. That dependency is now gone, both packages have been fixed and checked and independently audited, and the exact files that would be uploaded are built and sitting on this laptop. All that is left is the submission itself — safetyCharts now, and safetyGraphics only once safetyCharts has been accepted — through a web form on CRAN's site, fed from two repositories our agents are forbidden to write to, so the act is yours, and asking you for it is the entire purpose of this page.
One thing is not in the way. You are the named maintainer of both packages — your own address is in each package’s metadata, which is why CRAN’s check prints it back — so nothing here waits on anyone else’s permission, at CRAN or in the organisation the repositories sit under. The only reason an agent cannot do this for you is our own rule against writing outside your account, not a gate somebody else is holding.
You described this shape yourself tonight, before this page existed:
“Around the safety graphics resubmission stuff, we need to figure out how you get stuff like that added to the queue. I think probably, like, it's not a release in one of our packages, so it probably belongs in a decision artifact where you're just summarizing what was done and asking for approval to do the next step outside of... like, it's basically just a nonstandard action. Right? So you're asking for approval for a nonstandard action, which I think is fine.”
So this is the first page of its kind: a summary of what was done, and a request for approval to take the next step. The rule behind it is written down at the end, beside the three-bucket rule it extends.
The requirement asked for one thing: drop the archived charting package, and make both packages submittable again. That is finished, and it turned out to be larger than the requirement expected — most of the risk was not where anyone thought it was.
| safetyCharts | safetyGraphics | |
|---|---|---|
| Version prepared | 0.5.0 — CRAN last carried 0.3.0 | 2.2.0 — CRAN archived 2.1.1 |
| Check result | 1 note | 1 warning |
| What it says | “new submission” and “package was archived on CRAN” — every returning package carries these, and neither can be cleared | mostly that safetyCharts is not on CRAN yet, which clears the moment safetyCharts is accepted |
| Submittable today | yes | no — see the order below |
Five agents went at the branches and the write-up with an independent judging pass. It raised forty-nine items and confirmed eight real defects, including one behaviour change that had been introduced by accident and two false statements in files the packages would have shipped — the release notes CRAN prints on the package page, and the comment file that gets pasted into the submission form in your name. All eight are fixed, and they are listed on the hand-off rather than quietly folded in.
Each repository shipped a file, byte-identical in both, stating “there were no ERRORs, WARNINGs or NOTEs” from a version of R that is four years stale and three test machines that no longer exist. That file is what gets pasted into CRAN's comment box, in your name as maintainer. Both have been replaced with what the checks actually say.
The function is still there, still exported and still documented. Calling it raises an error that names the reason, the date, and how to draw the chart yourself from the archived package. The last working version stays in the repository's history under its release tag. One file was removed — the chart's configuration entry — and removing it is what takes the Tendril Plot out of the application's chart list. Nothing else was deleted in either package.
Neither branch was ever pushed. The prepared commits in both repositories exist on this laptop and nowhere else — no remote holds them, and the tarballs, the patch files and the check logs sit in a workspace folder that is not in any repository either. The laptop changes hands this weekend, and the same page that covers that move records that no backup destination is configured anywhere. So holding this decision is only free once the branches are pushed, and pushing them is an act only you can take, for the same reason the submission is.
Pushing the two branches costs one command each and commits you to nothing. It is worth doing whichever of the three answers below you choose, including the answer that never submits anything.
This is the one part of the whole exercise with no room in it. safetyGraphics requires safetyCharts, so while safetyCharts is merely pending, safetyGraphics has a dependency CRAN cannot see. Its check says so today, in a line that nothing anyone changes in safetyGraphics can clear: it reports safetyCharts as a strong dependency that is not in a mainstream repository. Only safetyCharts actually being on CRAN clears it.
safetyGraphics must wait until safetyCharts has been accepted by CRAN — not until it has been uploaded, and not until the automated pretest comes back green. A CRAN team member has stated in public that the dependency has to be accepted first or the dependents get automatically archived, which would mean archiving one of these packages a second time in the middle of un-archiving it.
The prepared work already enforces this rather than trusting anyone to remember. The comment file for safetyGraphics carries a do-not-submit banner at the top and two blanks — the version of safetyCharts and the date it was accepted — which cannot honestly be filled in until the first submission has landed. An earlier draft of that file asserted safetyCharts was already back on CRAN; the audit caught it, and it is now a placeholder behind the banner.
CRAN publishes nothing about how long a review takes. The only quantified figure anywhere is a community statistic — roughly a third of archived packages ever return, with a median of about a month — and that is a statistic about other people's packages, not a forecast for these two. Plan for the second submission being a separate errand on an unknown day rather than the same sitting.
The path was researched from primary sources and then verified adversarially. The important half is established. The rest is not, and it is set out here as not established rather than smoothed over, because a plausible-sounding process presented as fact is exactly the thing that would waste your evening.
The checks were run with the version of R on this laptop, which is three releases behind current, and CRAN asks for the check to be run with the current development version of R. There is a standard way to close that: one function call sends each tarball to CRAN's own Windows builder, runs the real check there, and emails you the result. It is a wait rather than work — the result comes back by email, and nobody here has timed how long that takes. It is an upload to a third party, so it was deliberately left for you rather than done on your behalf.
Push the prepared branch, run the development-version check on the tarball, upload it with the prepared comment, and accept the confirmation email. Then wait for acceptance and repeat for the second package. About an hour now and half an hour later, plus answering whatever CRAN asks in review.
What review is most likely to ask about: safetyCharts bundles sixteen third-party JavaScript libraries whose copyright holders are declared in none of the places CRAN looks — no copyright-holder role in the author list, no copyright field, no copyrights file — and only one of the sixteen ships its licence at all. That is not new — the identical set shipped in the version CRAN accepted in 2022 — but a returning package draws new-submission scrutiny, and this is the kind of thing it draws. Answering it properly means establishing who actually holds copyright on sixteen libraries, which is a project rather than a fix, and is not something to guess at in a submission.
This program is building an application to replace safetyGraphics, and it does not have a settled shape yet. Push both branches so the work survives the machine change, and stop there. Nothing is lost on the day, and the decision comes back when there is more to base it on.
The cost is that the work ages. The checks were run against a moving target — CRAN's checks tighten with every R release — so a submission months from now means re-running the whole verification rather than uploading what is on disk. And the person waiting keeps waiting, or gets told nothing is happening yet.
Push both branches, so the prepared work lives in each repository's history rather than on one laptop, and stop there. No submission, and the open request outside the program gets a plain answer saying so, so the people waiting can plan.
The cost falls on a specific group rather than in general. Installing either package the ordinary way stays broken permanently, and anyone in a validated or restricted environment that can only reach CRAN loses these packages outright — which is the population most likely to be using them in the first place.
Each is reversible in about a line. Only the first changes what anyone using the package experiences, and it is the one the requirement described differently — the requirement asked for the chart to be deprecated, and what was built raises an error rather than a warning. That substitution is why this is a question rather than a footnote.
| The call | What was chosen | What the alternative would have meant |
|---|---|---|
| The chart that caused all this | Calling it raises an error naming the reason, the date, and how to draw it yourself | A warning that returns nothing, which the app would then try to draw — a confusing failure instead of a clear one. There is nothing left to deprecate towards: the function's whole body was a call into the archived package |
| safetyCharts version | 0.5.0 | Reusing 0.4.0, which is already a public release in which the chart works — two different packages carrying one number |
| safetyGraphics version | 2.2.0 | 2.1.2. The unreleased work is features rather than fixes, so a minor bump is the honest description of it |
| The optional patient-profile tab | The package it needs is dropped from the declared list; the tab still works for anyone who installs that package from GitHub | Declaring it through an additional repository, which needs a live repository address that does not exist yet |
| Example code in the help pages | Runs on twenty subjects rather than the full dataset | The full data, which put two examples at 3.7 and 4.1 seconds against CRAN's five-second limit, on hardware faster than CRAN's |
| What ships inside the tarball | The rendered documentation site and a development scratch folder are excluded from the build, taking it from 1.55 MB to 539 KB | Shipping the scratch folder, as the 2022 version did. The documentation site never shipped to CRAN at all — it entered the repository a month after that release and had simply never been excluded from the build. Nothing is deleted; both are excluded from the build only |
On 17 August somebody outside this program opened a request on the safetyGraphics repository asking about exactly this — the CRAN archival and the dependency that caused it. It has no reply, no comment, and no reaction of any kind on it.
Nothing here has answered it and nothing here will. Agents in this program do not write anywhere outside repositories on your own account, and that rule holds even when you say a particular case is fine, because a rule with exceptions to remember is a rule that gets forgotten at the wrong moment. What is offered instead is a drafted reply that you paste.
The draft would say what has been done, that safetyCharts goes first and safetyGraphics follows on its acceptance, and it would not promise a date, because nobody honestly can. If you pick the third option above, the same draft says that instead — which is still a far better answer than silence.
Submit now, hold until the application being built to replace safetyGraphics has a settled direction, or stay off CRAN and say so. This is the approval the page exists for: a submission to an organisation outside every lane we have, from repositories our agents cannot touch.
Versions, what the retired chart does when called, what ships in the tarball, and how the examples run. Each is a line to reverse, and reversing one means rebuilding and re-checking that package before it goes.
Somebody has been waiting since 17 August for an answer that already exists. We cannot post it. We can write it.
Answer in words, in the Q&A thread or in chat. Quote a code if it helps — C1, C2, C3, or D0025.1 to D0025.3 — but you do not have to; naming what you want is enough.
The same applies to any other change you make: CRAN asks for the check to have been run on the file you actually upload, and that is the whole reason the rule exists.
Everything named here is already on disk, and the tarballs were verified to be builds of the branch tips as they stand tonight rather than assumed to be — which is exactly why the rebuild above is a step rather than a caveat:
Your queue holds three things: release candidates, decisions, and config items. This work fitted none of them. It is not a release of one of our packages, it is not something sitting on your keyboard, and until tonight it was not a decision either — so it fell through, and finished work sat in a chat message and a hand-off page instead of anywhere you would look for it.
Your answer was that it rides the decision bucket rather than becoming a fourth one: a non-standard action becomes a decision artifact that summarises what was done and asks approval for the next step. So the working rule, now written down beside the three-bucket rule itself so the two are read together, is this. A non-standard action is something outside our standard lanes, done or proposed by an agent, that needs your approval and is neither a release nor a config item. It reaches you as a decision artifact with a Q&A thread, exactly like this one, and it carries what was done, what state it is in, and the specific approval being asked for.
The test for whether something is one is simple enough to apply without thinking about it: if an agent has finished work and the next step is an act it cannot take, that step needs your approval, and there is no release and no configuration change in it — it is a non-standard action, and it becomes one of these pages.
Sources. The prepared work, the check results and the research on the route back are the worker hand-off of 20 August, read in full rather than summarised from its issue comment. Both CRAN package pages were fetched on 20 August and both still read that the package was removed from the CRAN repository, archived on 25 March as requiring an archived package. The open request outside the program was read from GitHub on 20 August: open, created 17 August, zero comments. The branch state was read locally, and both prepared branches were confirmed to exist on no remote — every branch containing those commits is a local one.
References. Requirement: obot.roadmap#281, and its outcome comment. Full hand-off, formatted for a phone: the CRAN hand-off page. The three-bucket rule this extends: obot.roadmap#220. The machine change and the backup finding: the laptop move. The unanswered request: SafetyGraphics/safetyGraphics#728. CRAN's package pages: safetyCharts, safetyGraphics.
Drafted by 👯🤖 W0095 using Claude Opus 5. Not reviewed by @jwildfire.