fix: final review corrections in proposal

- change pr processing#8666 from "merged" to "open" (accurate status)
- remove "this is itself a deliverable" over-explanation
- remove "this is my honest answer on it" defensive phrasing
- rewrite section 11 opener: drop "not because i am unsure" framing
- remove draft footer from end of file

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Author: Nixxx19

PROPOSAL_DRAFT.md

@@ -74,7 +74,7 @@ connie mentioned that the strongest proposals have three things: personal enthus
 
 ### 2.4 my existing contribution
 
-i already have a merged pr (#8666) on `dev-2.0` that fixes a crash in `parseObj()` at lines 655-658. the `hasColoredVertices === hasColorlessVertices` boolean logic error caused blender and sketchfab exports to throw instead of loading gracefully. i found this bug while reading `parseObj()` specifically to understand the code i would be working on for this project. it was not a separate investigation, it came directly out of the deep read i did for the proposal. this is also why i know exactly where the slicer needs to be inserted in that function.
+i have an open pr (#8666) on `dev-2.0` that fixes a crash in `parseObj()` at lines 655-658. the `hasColoredVertices === hasColorlessVertices` boolean logic error caused blender and sketchfab exports to throw instead of loading gracefully. i found this bug while reading `parseObj()` specifically to understand the code i would be working on for this project. it was not a separate investigation, it came directly out of the deep read i did for the proposal. this is also why i know exactly where the slicer needs to be inserted in that function.
 
 
 ## 3. the problem, stated precisely
@@ -360,7 +360,7 @@ the gsoc idea page lists this as 175h or 300h. i am proposing 300h because:
 
 1. the parser rewrite is non-trivial. vertex deduplication, uv mapping, and face winding all need to work correctly per-slice.
 2. visual tests for 3d rendering are significantly more complex than unit tests.
-3. after the feedback i received, i plan to allocate time to read all geometry-related references and file issues for unimplemented apis so other contributors can continue the work after gsoc. this is itself a deliverable.
+3. after the feedback i received, i plan to allocate time to read all geometry-related references and file issues for unimplemented apis so other contributors can continue the work after gsoc.
 4. the `buildGeometry()` integration (phase 4) is an extra deliverable not in the original spec.
 
 | phase | work | hours |
@@ -377,7 +377,7 @@ the gsoc idea page lists this as 175h or 300h. i am proposing 300h because:
 
 each phase estimate includes roughly 15 to 20 percent buffer for code review cycles, unexpected edge cases, and iteration. phases 3 and 4 carry the most risk since the vertex deduplication logic and the renderer buffer cache both have non-obvious interactions with the rest of the geometry pipeline. the 55h and 50h allocations for those phases reflect that risk. if a phase finishes under estimate the saved hours roll into phase 6 since testing can always absorb more time.
 
-buffer time came up in the group session and this is my honest answer on it: i do not treat these estimates as exact targets. i treat them as maximum allocations. the real goal is to finish phases 3 and 4 with enough headroom that testing is not squeezed. if something takes longer than expected in the parser, i will know early because i am already familiar with the code from writing pr #8666, and i can flag it before it cascades.
+buffer time came up in the group session. i do not treat these estimates as exact targets. i treat them as maximum allocations. the real goal is to finish phases 3 and 4 with enough headroom that testing is not squeezed. if something takes longer than expected in the parser, i will know early because i am already familiar with the code from writing pr #8666, and i can flag it before it cascades.
 
 
 ## 8. expected outcomes
@@ -458,7 +458,7 @@ that is 15 prs across the core library, the webgl renderer, and the editor. i ha
 
 ## 11. architectural decisions for the community bonding period
 
-i have researched each of these thoroughly and i have a clear position on each one. i am flagging them not because i am unsure what to do, but because decisions that touch the public api or shader pipeline should have explicit sign-off from the team before i write production code. i want to align early rather than have a pr review surprise.
+i have researched each of these thoroughly and have a clear position on each one. each decision touches the public api or shader pipeline and should have explicit sign-off from the team before i write production code. i want to align early rather than surface surprises at pr review.
 
 **decision 1: draw order for transparent slices**
 
@@ -515,5 +515,3 @@ adding a public `materialGroups` field to `p5.Geometry` seems like a smaller cha
 
 it satisfies every constraint at once: zero breaking changes, zero public api additions, zero documentation burden, full fallback guarantee for existing sketches, and it matches how processing4 handles it internally with `PShapeOBJ`. the underscore signals internal-only to contributors reading the code, and the renderer's `if (!geom._materialSlices)` check means every sketch that does not use multi-material models runs exactly the same code it always has.
 
----
-*this proposal will be updated after feedback from the mentors*