Repository navigation
[þing-02][DEFERRED] P2 — unwind the views_pipeline_core.modules.{appwrite,datastore} import #146
Description
Ratified follow-through from þing 02, ledger row P2. Already owed (register C-40, Tier 2). Deferred behind a named trigger: þ01-D8's supply trigger firing on the C-221 decomposition.
What. unfao.py:9-10 imports AppwriteConfig and DatastoreModule from views_pipeline_core. The sole writer of FAO's outbound bucket therefore runs another repo's client — its auto-provisioning, its discarded results, its delete branch — under this seat's name.
Why deferred rather than done. There is nothing to unwind to: views-pipeline-core has no supported client surface, file.py is 3,064 LOC with a confessed decomposition need and no owner decision, and exporting it is how a two-repo defect became three. Unwinding waits for the decomposition, not for this þing.
What is committed now, the smaller half: the DIP port at :37-77 already means wire/source_selection and wire/sink never see Appwrite types, so the surface to unwind is one adapter, not the delivery.
Recorded against this seat's own interest (orð_12 §2): an exported, supported client would make its life materially easier and retire C-40 for free. It declined to be cited as the demand trigger anyway — its import is the evidence for the decomposition, not an argument for sanctioning the surface.
Activity
Polichinel commentedon Jul 31, 2026
Added at ratification (þing 02, G4): record this as an ADR in this repo, alongside the deferral.
This issue is a deliberate, reasoned exception with an end condition — the import of
views_pipeline_core.modules.{appwrite,datastore}is kept knowingly, because there is nothing to unwind to until the C-221 decomposition lands, and it is deferred behind that named trigger rather than left undecided.That is exactly what an ADR is for, and it is currently recorded only in a deferred GitHub issue and in a deliberation folder (
views_platform/þingit/) this repo's maintainers have no reason to open. A deferred issue reads as "not done yet"; an ADR reads as "decided, for these reasons, until this condition changes" — which is the truth here.Write a short ADR in
docs/ADRs/covering: what is imported and why it is knowingly kept, what it costs (this seat runs another repo's client on FAO's outbound bucket, so that client's defects are live under this repo's name), the trigger that ends it, and the half already mitigated — the DIP port atunfao.py:37-77, which keeps Appwrite types out ofwire/source_selectionandwire/sink, so the surface to unwind is one adapter rather than the delivery.Polichinel commentedon Aug 1, 2026
Heads-up: a different D8 disjunct is about to fire
This issue defers P2 behind þ01-D8's supply trigger firing on the C-221 decomposition — correctly, and for good stated reasons.
Flagging only that D8 is
T1 ∨ T2 ∨ T3 ∨ (demand ∧ supply), and T1 — second consumer API clone — is imminent. Both gates on cuttingviews-crafdapicame down yesterday (views-faoapi#322 shipped in v1.4.0; the leaked key tested dead).This does not move your trigger. Yours is tied specifically to the supply clause and the C-221 decomposition, which has not happened. T1 firing does not decompose
file.pyand does not give you a surface to unwind to — which is the actual reason this is deferred.But if T1 activates Phase 1, the destination question opens on a schedule you would want to know about, since your unwind lands wherever the client ends up.
Tracked at views-platform/views-appwrite#23. No action requested.
Polichinel commentedon Aug 3, 2026
Scope update from #211 (views-postprocessing): P2 now covers two files, not one.
This issue's body says:
and commits the mitigation "the surface to unwind is one adapter, not the delivery".
views_postprocessing/crafd/managers/crafd.py(added in #211, the CRAF'd producer package) imports the same two symbols at the same lines. It is a near-verbatim copy of the FAO manager — both 406 lines, differing on 16 of them, none of it logic — so the adapter to unwind is now two adapters with identical contents.Nothing about the deferral changes. The named trigger stands as ratified: þ01-D8's supply trigger firing on the C-221 decomposition, explicitly not on this seat's convenience. There is still nothing to unwind to. This comment only corrects the scope, so that whoever picks P2 up when the trigger fires is not surprised by a second file.
Two related points from the same review, recorded here so they are not lost:
þing-02 S24(5) does not bind this import. The verdict addresses the repositories cut from views-faoapi (
views-crafdapi,views-productionapi); it does not reach a partner package inside this producer.docs/CLONING.mdhad cited it as a flat prohibition and over-claimed it — corrected in feat(crafd): CRAF'd producer package — clone of unfao/ (per CLONING.md) #211. What actually bounds the coupling here is repo-owned:tests/test_doc_accuracy.py::test_views_pipeline_core_has_exactly_one_importerpins the importer set to an explicit allowlist, so a third importer fails CI.The ADR this issue was asked for at ratification still does not exist.
docs/ADRs/runs 000–014 and none covers the deferral. The ratification comment's reasoning is unchanged and worth repeating: a deferred issue reads as "not done yet"; an ADR reads as "decided, for these reasons, until this condition changes." Register C-40 carries the reasoning today, which is better than nothing and is not the same thing.Register:
reports/technical_risk_register.mdC-40 (2026-08-03 amendment) and C-33.fix(guards): #211 — every partner-scoped guard was scoped to ONE partner
Polichinel commentedon Aug 4, 2026
ADR recorded — ADR-015: Why this repository imports another project's Appwrite client (#219).
This closes the condition attached at ratification: the reasoning now lives in the repository rather than only here and in the deliberation folder. This issue stays open — the ADR records the deferral, it does not discharge it.
Two things found while writing it that were not recorded anywhere in this repo:
The supply half of the trigger has partially moved. The verdict was written when pipeline-core's Appwrite module was a single 3,064-line file. As of 3.0.0 — which this repo now pins — provisioning and transport have been relocated into their own modules and an audit package exists alongside; the main file is 2,841 lines. There is still no exported client surface, so there is still nothing to unwind to and the trigger has not fired. But "nothing has moved" would be the wrong thing for the next reader to believe.
The sibling obligation from the same verdict is discharged. P1 required this repo's legacy delivery path to be guarded or retired before 2026-11-30. It was retired in #149 — the manager carries no such path and register C-63 is resolved. The deadline is moot here, and nobody had recorded that it was met.
Minor, but it cost me an hour:
C-221in the verdict is views-pipeline-core's register entry, not issue #221 — that issue is unrelated and closed. Noted in the ADR's appendix.Polichinel commentedon Aug 13, 2026
Scope correction: the import is in two files now, not one, and the body still says
unfao.py:9-10.Both partner managers do it:
views_postprocessing/unfao/managers/unfao.pyviews_postprocessing/crafd/managers/crafd.pyeach importing
AppwriteConfigandDatastoreModulefromviews_pipeline_core. The count is pinned —tests/test_doc_accuracy.pyasserts the importer list is exactly those two — so a third would fail CI, but the issue body would still send a reader to one file.The trigger has still not fired, and I checked rather than assumed. views-pipeline-core's
modules/appwrite/is nowfile.py,provisioning.py,transport.pyandaudit/, with__init__.pyre-exportingfile's symbols directly. The decomposition has moved; there is still no supported client surface to unwind to, which is exactly what this deferral says it waits for.The ratification condition attached to this issue is discharged — ADR-015 exists. Remains deferred, and remains views-pipeline-core's plate rather than ours.