You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
docs: ground Build Week README in real shipped PRs
Replace the aspirational GPT-5.6 Physics Critic section with an
evidence-based writeup of actual merged Codex/GPT-5.6 work, linking
real dated PRs instead of TODO placeholders.
@@ -658,15 +658,15 @@ Feedback and contributions are welcome.
658
658
---
659
659
660
660
661
-
> **OpenAI Build Week 2026:** Posecode existed before the hackathon. During Build Week, the project is being meaningfully extended with a GPT-5.6-powered biomechanical Physics Critic and an end-to-end Codex-built agent workflow. The sections below clearly distinguish previous work from new hackathon work.
661
+
> **OpenAI Build Week 2026:** Posecode existed before the hackathon. During Build Week, the project was extended using **Codex** — running on **GPT-5.6** — as the primary engineering tool for a real batch of shipped work: motion/grounding quality, language contract diagnostics, licensing restructuring, release automation, and product-facing pages. The sections below distinguish previous work from Build Week work using actual commit history, not a roadmap.
662
662
663
663
---
664
664
665
665
## OpenAI Build Week Extension
666
666
667
-
### What existed before July 13, 2026
667
+
### What existed before Build Week
668
668
669
-
Before OpenAI Build Week, Posecode already included:
669
+
Before Build Week, Posecode already included:
670
670
671
671
- the core `.posecode` domain-specific language,
672
672
- a parser and intermediate motion representation,
@@ -683,205 +683,56 @@ This original version was developed primarily with **Claude** as an AI-assisted
683
683
684
684
That prior work provides the foundation for the project, but it is not presented as the new hackathon contribution.
685
685
686
-
### What is being added during Build Week
686
+
### What was added during Build Week
687
687
688
-
During the July 13–21 Build Week submission period, Posecode is being meaningfully extended with:
688
+
Every item below is a merged, dated pull request built with Codex (GPT-5.6) — see [Build Week Evidence](#build-week-evidence) for direct links.
689
689
690
-
1.**GPT-5.6 Physics Critic**
691
-
2.**Biomechanical fidelity scorecard**
692
-
3.**Natural-language-to-motion agent workflow**
693
-
4.**Interactive generation and critique experience**
694
-
5.**Codex-built tests, tooling, and renderer improvements**
695
-
696
-
The new workflow allows a user to describe a movement in ordinary language, generate structured Posecode, validate it deterministically, and receive a detailed GPT-5.6 critique explaining biomechanical or spatial problems.
690
+
1.**Motion and grounding overhaul** — ROM-constrained reach IK, semantic palm/fist/sole/knee/pelvis contact surfaces, multi-contact refinement, stable support handoffs, and XBot-aware grounding ([#76](https://github.com/posecode-dev/posecode/pull/76)).
691
+
2.**Language contract and diagnostics** — Posecode language/IR v0.3 custom start-pose blocks with ROM-checked overrides, live and clip-wide grounding/self-collision diagnostics, and an accessible metric floor guide ([#92](https://github.com/posecode-dev/posecode/pull/92)).
692
+
3.**Licensing restructure** — split the monorepo into an Apache-2.0 standard layer (spec, parser, share, language, LSP, VS Code) and an AGPL-3.0 product layer (render, embed, MCP, eval, playground), with a commercial-license path ([#84](https://github.com/posecode-dev/posecode/pull/84)).
693
+
4.**Release automation** — Changesets-driven npm publishing via GitHub OIDC, MCP Registry publishing, and CI validation of package versions, entry points, and tarball contents ([#66](https://github.com/posecode-dev/posecode/pull/66)).
694
+
5.**Third-party integration readiness** — Posecode 0.2 timing vocabulary (`drive`/`settle`/`flow`/`snap`), a parser validation CLI, and embed compatibility metadata ([#62](https://github.com/posecode-dev/posecode/pull/62)).
695
+
6.**Ground-lock correctness** — parser-owned validation for per-side foot/hand/elbow ground locks and back-contact support for supine movements, replacing silent acceptance of invalid contacts ([#61](https://github.com/posecode-dev/posecode/pull/61), [#64](https://github.com/posecode-dev/posecode/pull/64)).
696
+
7.**LLM-first landing page and product page** — redesigned the landing page around a prompt → Posecode → live 3D story, and added a `/for-products` page documenting the web component, parser, renderer, and MCP server for integrators ([#82](https://github.com/posecode-dev/posecode/pull/82), [#74](https://github.com/posecode-dev/posecode/pull/74)).
697
+
8.**Mobile and search fixes** — mobile toolbar/viewer layout, natural hand orientation, and Google Search indexing corrections ([#78](https://github.com/posecode-dev/posecode/pull/78), [#65](https://github.com/posecode-dev/posecode/pull/65)).
A movement can be syntactically valid while still being awkward, unstable, unsafe, or physically implausible.
716
-
717
-
For example:
718
-
719
-
```posecode
720
-
step "Twist" 1s:
721
-
hips: rotate 0
722
-
spine: rotate 90
723
-
feet: lock
724
-
```
725
-
726
-
A parser may understand this program, but the movement may create an unrealistic torso rotation while the hips and feet remain locked.
727
-
728
-
The new **Physics Critic** sends the structured movement, parser warnings, joint states, and geometric measurements to GPT-5.6.
729
-
730
-
GPT-5.6 then returns a structured critique such as:
731
-
732
-
```json
733
-
{
734
-
"score": 42,
735
-
"summary": "The movement is syntactically valid but biomechanically implausible.",
736
-
"issues": [
737
-
{
738
-
"severity": "high",
739
-
"category": "spinal_rotation",
740
-
"message": "Torso rotation is excessive while the pelvis and feet remain fixed.",
741
-
"suggestion": "Reduce spinal rotation or allow the pelvis and feet to rotate."
742
-
}
743
-
]
744
-
}
745
-
```
746
-
747
-
The critic does not replace deterministic safety checks. It adds a semantic reasoning layer on top of the real Posecode parser and kinematic engine.
748
-
749
-
---
750
-
751
-
## Fidelity Scorecard
752
-
753
-
The Build Week scorecard combines deterministic measurements with GPT-5.6 analysis.
754
-
755
-
It can evaluate:
756
-
757
-
- joint range-of-motion compliance,
758
-
- balance and support,
759
-
- movement continuity,
760
-
- left-right consistency,
761
-
- torso and pelvis coordination,
762
-
- foot-ground contact,
763
-
- reachability,
764
-
- abrupt transitions,
765
-
- and overall biomechanical plausibility.
766
-
767
-
Conceptually, the total score is:
768
-
769
-
$$
770
-
F = \sum_{i=1}^{n} w_i s_i
771
-
$$
772
-
773
-
where:
774
-
775
-
-\(s_i\) is the score for one fidelity dimension,
776
-
-\(w_i\) is that dimension's weight,
777
-
- and \(\sum_{i=1}^{n} w_i = 1\).
778
-
779
-
The purpose of the score is not to provide medical advice. It gives developers and AI agents a transparent signal for comparing, debugging, and improving generated movement.
780
-
781
-
---
782
-
783
711
## How GPT-5.6 Is Used
784
712
785
-
GPT-5.6 is used as a spatial and biomechanical reasoning layer.
786
-
787
-
It supports two Build Week workflows.
788
-
789
-
### 1. Natural language to Posecode
790
-
791
-
A user can enter:
792
-
793
-
> Perform a controlled forward lunge, keep the torso upright, pause at the bottom, and return to standing.
794
-
795
-
GPT-5.6 translates that request into a structured `.posecode` program with:
796
-
797
-
- participating joints,
798
-
- semantic joint actions,
799
-
- approximate angles,
800
-
- movement phases,
801
-
- timings,
802
-
- cues,
803
-
- and grounding constraints.
804
-
805
-
The output is not sent directly to the renderer.
806
-
807
-
It must pass through the deterministic Posecode pipeline:
808
-
809
-
```text
810
-
Natural-language request
811
-
↓
812
-
GPT-5.6 generation
813
-
↓
814
-
Posecode parser
815
-
↓
816
-
ROM validation
817
-
↓
818
-
Forward and inverse kinematics
819
-
↓
820
-
Geometric fidelity checks
821
-
↓
822
-
WebGL renderer
823
-
```
824
-
825
-
### 2. Physics Critic
826
-
827
-
After parsing and evaluating the movement, GPT-5.6 receives structured information about:
828
-
829
-
- the original user request,
830
-
- generated Posecode,
831
-
- parser warnings,
832
-
- clamped joint values,
833
-
- movement phases,
834
-
- support points,
835
-
- kinematic measurements,
836
-
- and failed fidelity invariants.
837
-
838
-
GPT-5.6 uses this information to explain:
713
+
During Build Week, Codex sessions ran on **GPT-5.6** (GPT-5.6 Terra), which is the model that powers Codex for this event. GPT-5.6 is the reasoning engine behind every Build Week change listed above: reading the existing monorepo, proposing the ROM-constrained IK and contact-surface design in [#76](https://github.com/posecode-dev/posecode/pull/76), designing the language/IR v0.3 diagnostics in [#92](https://github.com/posecode-dev/posecode/pull/92), and drafting the licensing boundary in [#84](https://github.com/posecode-dev/posecode/pull/84).
A GPT-5.6-powered natural-language-to-Posecode generation feature (describe a movement in plain English, get a validated `.posecode` document back) is a natural next step given the existing [`posecode_authoring_guide` MCP tool](packages/posecode-mcp/README.md), but it is **not yet built** — it is not claimed as shipped functionality here.
850
716
851
717
---
852
718
853
719
## How Codex Is Used
854
720
855
-
Codex is the primary engineering tool used for the new Build Week extension.
856
-
857
-
During the hackathon period, Codex is used to help:
721
+
Codex is the primary engineering tool used for the Build Week extension.
858
722
859
-
- inspect and understand the existing monorepo,
860
-
- design the Physics Critic architecture,
861
-
- implement GPT-5.6 API integration,
862
-
- define structured generation and critique schemas,
863
-
- build new MCP tools,
864
-
- create the fidelity-score pipeline,
865
-
- add playground UI components,
866
-
- implement movement revision workflows,
867
-
- debug coordinate and skeletal transformation issues,
868
-
- write unit and integration tests,
869
-
- create evaluation fixtures,
870
-
- improve error handling,
871
-
- and document the new system.
723
+
During the hackathon period, Codex was used to:
872
724
873
-
Codex accelerates implementation, but the project remains human-directed.
725
+
- inspect and understand the existing monorepo before each change,
726
+
- design and implement the ROM-constrained reach IK and contact-surface system ([#76](https://github.com/posecode-dev/posecode/pull/76)),
727
+
- design and implement the language/IR v0.3 diagnostics and floor guide ([#92](https://github.com/posecode-dev/posecode/pull/92)),
728
+
- restructure package licensing across the monorepo ([#84](https://github.com/posecode-dev/posecode/pull/84)),
729
+
- build the Changesets/OIDC npm and MCP Registry release pipeline ([#66](https://github.com/posecode-dev/posecode/pull/66)),
730
+
- fix ground-lock validation and silent-acceptance bugs ([#61](https://github.com/posecode-dev/posecode/pull/61), [#64](https://github.com/posecode-dev/posecode/pull/64)),
731
+
- redesign the landing page and add the product integration page ([#82](https://github.com/posecode-dev/posecode/pull/82), [#74](https://github.com/posecode-dev/posecode/pull/74)),
732
+
- write unit, integration, and evaluation-harness tests for each change,
733
+
- and fix mobile UI and search-indexing regressions.
874
734
875
-
The following decisions are reviewed and selected manually:
876
-
877
-
- DSL semantics,
878
-
- system architecture,
879
-
- prompt design,
880
-
- scoring dimensions,
881
-
- biomechanical constraints,
882
-
- validation policy,
883
-
- user experience,
884
-
- and acceptance or rejection of generated code.
735
+
Codex accelerates implementation, but the project remains human-directed. The following decisions were reviewed and selected manually: DSL semantics, system architecture, licensing boundaries, biomechanical constraints, validation policy, user experience, and acceptance or rejection of generated code.
885
736
886
737
### Codex development workflow
887
738
@@ -892,46 +743,51 @@ The Build Week workflow follows this process:
892
743
3. Request one or more possible approaches.
893
744
4. Review the trade-offs and choose the architecture.
894
745
5. Use Codex to implement the selected approach.
895
-
6. Run type checking, tests, and fidelity evaluations.
746
+
6. Run type checking, tests, and biomechanical evaluations (`npm run eval`).
896
747
7. Inspect failures manually.
897
748
8. Refine the implementation with additional Codex sessions.
898
749
9. Review the final changes before committing.
899
750
900
751
### Codex session
901
752
902
-
903
753
```text
904
-
Codex /feedback session ID: TODO
754
+
Codex /feedback session ID: TODO — run /feedback in the Codex thread where the majority
755
+
of this Build Week work was built, then paste the resulting Session ID here.
905
756
```
906
757
907
758
---
908
759
909
760
## Build Week Evidence
910
761
911
-
The repository history will distinguish pre-existing functionality from work completed during the hackathon.
912
-
913
-
### Build Week commits
762
+
All Build Week work is public, dated, and directly linked below — no placeholders.
0 commit comments