102 lines
4.7 KiB
Markdown
102 lines
4.7 KiB
Markdown
# FLUSH FIDGET — shared agent prompt
|
|
|
|
Every agent (Claude, Codex, Grok) reads this file first. It is the single source of
|
|
truth for the project. If something here is wrong, say so in COORDINATION.md; do not
|
|
quietly work around it.
|
|
|
|
## Goal
|
|
|
|
Orca Slicer wastes most of the filament on a multi-colour print as purge: one real
|
|
4-colour slice used 94 g of purge and prime tower against 19 g for the model itself
|
|
(392 filament changes). Make that purge land in a **flush fidget** instead of the
|
|
tower or a waste bin.
|
|
|
|
The flush fidget is the print-in-place Flexi Cube at `assets/flexi cube.stl`.
|
|
Getting that one file through the whole process is the goal: slice it as the purge
|
|
target, print it, and have it still flex.
|
|
|
|
**Random colours on the outside are wanted.** Purge showing on the exterior in
|
|
unplanned colours is the desired look, not a defect. Do not hide it inside infill.
|
|
|
|
## Repositories
|
|
|
|
- This repo (docs, prompt, STL, patches): `http://10.0.10.2:3000/fred/flush-fidget.git`
|
|
- Orca fork (code changes go here): `http://10.0.10.2:3000/fred/OrcaSlicer.git`
|
|
A plain copy of upstream `OrcaSlicer/OrcaSlicer`, not a mirror, so you can push
|
|
branches. Upstream has 75 branches. Branch from `main`. Add upstream as a remote:
|
|
`git remote add upstream https://github.com/OrcaSlicer/OrcaSlicer.git`.
|
|
Both repos are private. Fred will give each agent its own token.
|
|
|
|
## Success test
|
|
|
|
Slice a 4-colour model with the Flexi Cube on the plate as the purge target. Then:
|
|
|
|
1. The Flushed + Tower totals in Orca's filament table drop substantially against
|
|
the baseline recorded in `tests/baseline.md`. Ideal: no prime tower at all.
|
|
2. The G-code preview shows purge extruded into the Flexi Cube, with mixed colours
|
|
on its outer surface.
|
|
3. The printed cube still moves. Colour-change purge must not fuse the joints or
|
|
fill the clearances. This is the hard constraint and the likeliest failure.
|
|
|
|
## The core problem
|
|
|
|
Purge needed per layer depends on the colour changes on that layer. The cube has a
|
|
fixed cross-section per layer. They won't match. Layers needing more purge than the
|
|
cube can take, and layers needing less, both have to be handled. Any design that
|
|
ignores this will look right in the preview and fail on the printer.
|
|
|
|
## Rules
|
|
|
|
- Smallest change that works. Do not rewrite the slicer.
|
|
- Label every claim VERIFIED (you read the code or ran it) or UNVERIFIED. File paths
|
|
in this document are guesses until an agent confirms them. A starting guess for the
|
|
tower code is `src/libslic3r/GCode/WipeTower.cpp` and `WipeTower2.cpp`.
|
|
- Metric units. No new dependencies without asking Fred.
|
|
- Orca Slicer is AGPL-3.0. Keep upstream as a remote. Keep the licence intact.
|
|
- Only touch this repo and the Orca fork. Never touch Fred's other workspace files.
|
|
- Do not push to `main`. Do not push anywhere public. Fred decides when anything is
|
|
published.
|
|
- Never print without Fred present.
|
|
|
|
## Team protocol
|
|
|
|
- Each agent works in its own git worktree on `agent/<name>/<task>`.
|
|
- Claim a task in `COORDINATION.md` before starting. Two agents never edit the same
|
|
file at once. Claude merges.
|
|
- Write findings to `recon/<name>-<topic>.md` with file paths and line numbers.
|
|
- Put code changes in the Orca fork. Keep the resulting patches in `patches/`.
|
|
|
|
## Phases
|
|
|
|
**Phase 0 — Baseline (Claude).** Build Orca from source on this machine. Record the
|
|
exact commands and build time in `tests/baseline.md`. Slice the reference model and
|
|
record its Flushed and Tower totals there. Nothing proceeds until this works.
|
|
|
|
**Phase 1 — Recon, read-only.**
|
|
- Codex: trace how the prime tower is generated layer by layer, and where the flush
|
|
matrix and multiplier feed in.
|
|
- Grok: trace the existing "flush into objects' infill / support / this object"
|
|
feature. Where does purge get routed into an object, and what limits how much it
|
|
absorbs?
|
|
- Claude: inspect `assets/flexi cube.stl`. Report its volume per layer, joint
|
|
clearances, and wall thickness. Then set out the options for reconciling purge
|
|
volume with that cross-section, with effort and risk for each.
|
|
|
|
**STOP after Phase 1. Report to Fred. Write no code until Fred approves one option.**
|
|
|
|
## Options to evaluate (do not implement yet)
|
|
|
|
1. No code: use the existing flush-into-this-object feature with the cube as the
|
|
target. Say whether it is enough on its own.
|
|
2. Extend flush-into-this-object so the chosen object absorbs more, including onto
|
|
its outer surface.
|
|
3. Replace the tower geometry with the cube. Likely hardest.
|
|
|
|
For each: files touched, effort, and what breaks. Option 2 or 3 must say how the
|
|
joints stay free.
|
|
|
|
## Reporting
|
|
|
|
Short and plain. Lead with the answer. If you are unsure, say so and say what would
|
|
settle it. Fred has ADHD: no walls of text, no unrequested tangents.
|