add-torch-shapes-example

You are importing a PyTorch model into Pyrefly's example corpus at tensor-shapes/pyrefly-torch-stubs/examples/. This is the contribution case the porting skill describes: these ports are tested reference material that others read to learn the patterns, so produce its fuller deliverable — paste every artifact (audit table, per-local revealtype dumps, typed-interface receipts, exhaustive asserttype coverage, completion report) in full, not just the annotated model.

Why these ports matter. They demonstrate what happens when you write a real PyTorch model with tensor shape types, proving real-world utility. If you exclude features or simplify the model, you prove nothing — the hard parts are exactly where the value needs to be demonstrated. So port the model faithfully and in full (see step 2).

Improving the stubs is the point, not a side quest. In the general porting skill, changing stubs is optional and a missing shape can just be documented as a gap. Here it is the opposite: a corpus example exists to exercise and harden the stubs. When an op falls back to bare Tensor, treat it as a stub deficiency to fix, not a gap to record — refine the stub signature (or add a shape DSL rule) so the shape is recovered, then make that the general truth about the op, not a special case for this model. A port that leaves easily-fixable bare Tensors behind is not done. Only genuinely data-dependent shapes (e.g. data-dependent token counts) should remain bare, with a comment saying why.

1. Run the port

Do the actual porting by reading and following the add-shape-types-to-torch-model skill's SKILL.md (in tensor-shapes/skills/add-shape-types-to-torch-model/) end to end — its gated workflow (pre-flight gates → per-module loop → verification) is the algorithm.

That skill opens with two questions for the user; for corpus work you already have the answers, so don't stop to ask: the check command is the buck invocation in step 3 below, and stub changes are in scope (corpus ports should track shapes as fully as possible, so refine stub signatures when that recovers real shapes). Produce all of its output artifacts; for the corpus they are required.

2. Place the file

Write the port at tensor-shapes/pyrefly-torch-stubs/examples/<model>.py. Every class, function, and method from the original belongs in the port — the corpus values completeness.

3. Verify (the fbsource commands)

The porting skill's verification phase tells you to run verify_port.sh and then "the actual Pyrefly check." In fbsource that check is a buck invocation against the shape-aware stubs:

buck build fbcode//pyrefly/tensor-shapes:torch-stubs-search-path
buck run fbcode//pyrefly:pyrefly -- check --config /dev/null --python-version 3.13 --tensor-shapes true --search-path "$(buck targets --show-output fbcode//pyrefly/tensor-shapes:torch-stubs-search-path | awk '{print $2}')" tensor-shapes/pyrefly-torch-stubs/examples/<model>.py

The result must be 0 errors, with no leftover reveal_type.

Then run the corpus test target so the new example is covered by CI:

python3 tensor-shapes/pyrefly-torch-stubs/run_pyrefly.py --buck --suite torch-examples

If you hit a wrong or missing shape

A missing shape (op falls back to bare Tensor) is usually a loose or absent stub signature — fix it in the stubs so the shape is recovered (see "Improving the stubs is the point" above), rather than documenting it as a gap.

A wrong shape (Pyrefly computes a concrete shape that's incorrect) or a missing shape that can't be expressed by a stub signature alone is a shape-DSL change: see the modify-shaped-array-dsl skill. That skill insists on unit-testing the DSL logic, not just relying on this example to exercise it. Don't reach for the DSL for shapes a stub signature could express.