feat: run a pipeline inside a project

[camielvs]

Description

A project can hold pipelines and it can list runs, but nothing in the app could make a run that belongs to a project — the run feed was read-only, and the one run attached to a project on the dev backend had been put there by something other than this app.

The association already exists in the backend's read path: a run belongs to a project when it carries the run-level annotation tangleml.com/project/project-id/<project_id>. So this is not a new data model, it is the missing write path.

All three ways in are here: from the project page, from the editor, and by rerunning a run that already belonged to one.

Memberships are a set, not a field

The project id lives in the annotation's key, with a constant value. That makes these annotations a set of memberships: a run can belong to several projects at once. The data layer is plural (projectIds) for that reason, even though each way of starting a run picks one — which also means a rerun can carry a multi-project run's attribution across without dropping any.

Attribution is write-once

PUT /api/pipeline_runs/{id}/annotations/{key} takes the key as a path segment, and 404s on this key — URL-encoded or raw — while a slash-free key on the same run returns 200. Probed both ways.

So there is no repairing a run that was submitted unattributed, and no revoking one that was attributed wrongly. Attribution has to be right at submission. That prices every "the project id is quietly dropped" path as permanent, and is why the remaining cases validate the id where it comes from somewhere untrusted, and keep it verbatim where it is a historical fact.

Where the project comes from

Every run in the app is created through one function, submitPipelineRun, so the project travels as one option on it and all three entry points share it. What differs is only where the id comes from.

From the project page, it is definitional — you pressed the button on a resource row of that project, so there is nothing to validate. The preview already holds the parsed spec for a pipeline the backend holds and for one held in this browser, so both can be run, and the existing argument dialog is reused as-is rather than growing a second arguments UI.

In the editor, it lives in the ?projectId= search param rather than in component state, for two reasons. A reload or a duplicated tab keeps it, which is what "the runs of this tab" has to mean; and the chip that names it is nowhere near the submitter that acts on it — in the v2 editor the submitter is sr-only — so both read one value instead of keeping two copies that can disagree. The dialog's project field writes that same param, so the field and the chip are two views of one answer. An id off a link or a bookmark is only acted on once a project answers to it: a project that is merely slow, or a backend failing for some other reason, keeps the attribution, and only a project that is gone drops it. With the flag off the param is ignored altogether, so a shared url cannot attribute runs in a UI that never mentioned a project.

On a rerun, it is read from the run being rerun, and every project of it rather than one. The read happens inside the mutation, not on render: a click that beat it would submit a copy belonging nowhere. The read is also allowed to fail the rerun, since a refused rerun is something you can simply do again, where losing the attribution is permanent. Nothing is asked of the backend when projects are off, so reruns elsewhere in the app cannot fail this new way.

Which projects hold a pipeline has no endpoint to ask — and resources cannot be filtered by what they point at — so it is one resource listing per project, read through the very query the project page already uses. No second cache to invalidate: a pipeline just added to a project is offered immediately.

Also here

• A project's run feed is invalidated when a run starts in it. Nothing invalidated that key before; it is 5-minute-stale, so a run you had just started appeared to have gone nowhere. The invalidation is deliberately narrow — ["projects", id, "runs"] — because the resource mutations document why the loose ["projects", id] prefix must not be invalidated, and a test pins that.
• The offer to copy arguments from a past run is withheld for a backend pipeline. Those runs are found by the pipeline's name in this browser, so for a pipeline the backend holds they would belong to a different pipeline that merely shares its name — the same confusion the sibling PR just fixed for the editor link, three lines above in the same file.
• A pipeline that does not validate is not offered at all, rather than submitted to fail.
• The post-submit notes/tags writes are now shared rather than private to the editor's submitter, so notes typed on the project page are kept instead of silently dropped.
• The same run's annotations were cached under three different keys, one of them varying by whether the id arrived as a string or a number, so the same data was fetched repeatedly and never shared. They now go through one set of query options — which is also why a rerun usually finds them already loaded.
• One import fixed so the "leaf utils import annotation keys from the keys module" rule is true rather than nearly-true.

Verification

npm run validate and the full suite green — 2815 tests. Among them: that a submission with no project is byte-identical to today's (every run in the app goes through this path, so that is a regression guard rather than a feature test); that a digits-only project id arriving as a number is still read as a string, since the router JSON-parses search params; and that a junk param attributes nothing rather than inventing a project.

Not yet verified in a browser. The end-to-end claim that matters — that the backend accepts the annotation we write at creation and then returns the run in the project's feed — has only unit coverage so far. The script for it is written and waiting; the dev backend was unavailable when it came time to run it. Worth doing before this merges.

Known limitations

• Run status does not advance on the project page. Each row's status is a separate query with no refetch interval, so a run submitted here shows its opening status and then sits there until the page is remounted. Pre-existing, but this PR is what makes it visible, and it is worth fixing next.
• Running a pipeline into a project does not add the pipeline to that project. The field only offers projects that already hold it.
• Membership is computed client-side and reads only the first page of projects, and of each project's resources. Cheap at today's scale, but it grows with a reader's project count rather than with anything about the pipeline. A ?pipeline_id= filter on the projects list would remove the whole scan — worth raising with the backend team.
• A pipeline renamed without ever having a registry id is not recognised as belonging to its projects, so it is missing from the field. Same limit the preview already documents, and it fails by omission rather than by pointing at the wrong pipeline.
• Notes and tags are still written as two fire-and-forget requests after the run exists, neither with an error handler, so a failed write loses what was typed. They would be better carried in the submission body beside the project annotation. Left alone here: changing how every run in the app records its notes does not belong in a projects PR.

🤖 Generated with Claude Code

[github-actions]

🎩 Preview

A preview build has been created at: 09-18-feat_run_a_pipeline_in_a_project/96a6606

[camielvs]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• fix(runs): say why the backend refused a run instead of that it did #2794 : 2 dependent PRs (#2796 , #2798 )
• feat(tangent): brief the agent on naming, and on the project its runs belong to #2792
• feat(projects): fix cancelling, track shared projects, flag unreachable pipelines #2790
• feat(tangent): keep an agent's edits in frame on the canvas #2789
• feat(tangent): bring Tangent onto the dashboard #2787
• feat(tangent): show a project's runs on the tangent page #2786
• fix(projects): show an agent's run on the project it belongs to #2785
• fix(agent): submit a spec that came from the editor's store #2784
• chore: increase max turns in remote agent #2779
• fix(tangent): stop the tab strips scrolling up and down #2777
• feat(projects): make the agents' instructions a project document #2776
• feat(tangent): list the pipelines the backend holds #2775
• feat(projects): show a project's documents on both pages #2774
• fix(tangent): project window parity — share, new-session links, agent-created pipelines, and a folded-away project window #2773
• refactor(projects): describe a project's resources one way #2765
• feat(projects): delete and share a project from either page #2764
• feat: open a new project ready to work in #2763
• feat: let the project page and Tangent reach each other #2762
• fix: keep a long project name inside the tile it belongs to #2761
• feat: say so when Tangent cannot be reached #2760
• feat: open a project where the work happens #2759
• feat: run a pipeline inside a project #2754 👈 (View in Graphite)
• feat: add pipelines held in this browser to a project #2745
• feat: project page #2738
• feat: create a project from a tile in the grid #2735 : 2 other dependent PRs (#2736 , #2737 )
• feat: projects dashboard #2734
• chore: tangent - annotate runs submission to projectid #2758
• fix: tangent - proper debug sequence system prompt #2757
• fix: tangent - quick run button from mini content window #2744
• fix: tangent - remote agent send delta immediately #2743
• fix: tangent - mint proper authorization with tangent #2742
• feat: tangent - debug in tangent sequence #2741
• chore: add autolayout tool #2740
• feat: tangent - resource management via document entity #2733
• feat: tangent - interactive chips in tangent chat #2732
• chore: save id stack to replay ids on reloads #2731
• refactor: tangent - migrate tangetproectcontext onto mobx #2730
• feat: tangent - keep track of open tabs while switching sessions inside project #2729
• feat: tangent - remote agent for runview and editor #2728
• refactor: tangent - structured workarea target #2727
• feat: tangent - embedded pipeline run view #2726
• feat: tangent - embedded pipeline editor #2725
• feat: tangent - dynamic workarea remote tools #2724
• feat: tangent - resources management in project view #2723
• feat: tangent project view page #2722
• feat: workspaces and projects service #2720
• chore: api client for workspaces and projects #2719
• master

This stack of pull requests is managed by Graphite. Learn more about stacking.