diff --git a/src/constants/MarkdownFiles/posts/2026-08-05-gsoc-26-ashutoshx7-week10.md b/src/constants/MarkdownFiles/posts/2026-08-05-gsoc-26-ashutoshx7-week10.md new file mode 100644 index 00000000..183eab51 --- /dev/null +++ b/src/constants/MarkdownFiles/posts/2026-08-05-gsoc-26-ashutoshx7-week10.md @@ -0,0 +1,120 @@ +--- +title: "GSoC '26 Week 10 Update by Ashutosh Singh" +excerpt: "Activity creation grows beyond a single text prompt: multiple learning areas now travel through the whole pipeline, previews and version review become clearer, and visual references arrive in the v1.3.0 release." +category: "DEVELOPER NEWS" +date: "2026-08-05" +slug: "2026-08-05-gsoc-26-ashutoshx7-week10" +author: "@/constants/MarkdownFiles/authors/ashutosh-singh.md" +description: "GSoC'26 Contributor at SugarLabs working on Sugar Activity on Demand" +tags: "gsoc26,sugarlabs,week10,ashutoshx7,visual-reference,multimodal,learning-areas,preview,release,ai,llm" +image: "assets/Images/GSOC.webp" +--- + + + +# Week 10 Progress Report by Ashutosh Singh + +**Project:** [Sugar Activity on Demand](https://github.com/sugarlabs/GSoC/blob/master/Ideas-2026.md#sugar-activity-on-demand)
+**Mentors:** [Walter Bender](https://github.com/walterbender), [Ibiam Chihurumnaya](https://github.com/chimosky)
+**Reporting Period:** July 28, 2026 to August 3, 2026 + +--- + +## Goals for This Week + +- Carry the reflection sidebar from a prototype into the main project +- Make learning areas real generation context rather than a decorative UI choice +- Improve preview and version review so learners can understand what changed +- Let a learner begin with an image as well as words +- Cut releases around stable, testable milestones + +--- + +## This Week's Achievements + +Week 9 ended with a lesson about pointing: when someone wants to change an activity, they naturally point at the part they mean. This week I followed that idea in the other direction. Sometimes the clearest way to explain what you want to create is not a longer paragraph. It is a sketch, a worksheet, a screenshot, or a photo of something you want to build from. + +That led to the biggest addition of the week: a complete visual-reference workflow. Alongside it, I tightened the existing preview and revision experience, carried multiple learning areas through every stage of generation, and released those improvements as [v1.2.0](https://github.com/sugarlabs/Sugar-activity-on-Demand/releases/tag/v1.2.0) and [v1.3.0](https://github.com/sugarlabs/Sugar-activity-on-Demand/releases/tag/v1.3.0). + +### 1. Learning Areas Became Part of the Specification + +The creation screen already let a learner describe an idea, but a single category was too restrictive. A project can be both science and drawing, or language and games. I changed the activity specification to support multiple learning areas and then followed that data all the way through the system. + +The selected areas are now: + +- Stored in saved project plans and restored when a project is reopened +- Included in clarification questions, so the questions fit the learning goal +- Passed into prompt enhancement without replacing the learner's original intent +- Combined in the generation prompt and retained in the final plan + +This was a good example of a UI feature that is only real when the backend agrees with it. Multi-select chips on the screen would have meant nothing if the planner silently reduced them to one value later. + +### 2. Clearer Preview and Version Review + +The live preview and version history from Week 8 worked, but reviewing a generated activity still asked too much of the learner. I polished the preview states, made generation failures easier to distinguish from preview failures, and improved the review view so moving between revisions gives a clearer picture of what the studio produced. + +I also simplified the creation controls and their defaults. The aim was to keep the common path short while leaving the advanced controls available. A learner should be able to choose an area, describe an idea, and start; they should not have to understand provider routing or validation modes before making their first activity. + +### 3. Creating From a Visual Reference + +The new reference workflow lets a learner attach an image to the idea they type. The studio prepares a safe preview, sends the image only through a provider that supports visual input, and turns the analysis into context for clarification and generation. + +That opens several useful starting points: + +- A hand-drawn layout for a game +- A classroom worksheet that could become interactive +- A screenshot whose structure a learner wants to remix +- A photograph that inspires a science, language, or storytelling activity + +Provider support was the difficult part. Not every model or API accepts images in the same format, and some do not accept them at all. I added explicit capability handling and a fallback analysis path rather than letting an image fail somewhere deep inside generation. The text prompt remains the source of intent; the image adds evidence instead of taking control away from the learner. + +### 4. Two Releases in One Week + +On July 30, I tagged **v1.2.0** around the improved activity preview and version-review experience. On August 3, the visual-reference workflow became **v1.3.0**. + +Keeping these as separate releases made the progression easy to review. v1.2.0 improved how learners inspect what they have made. v1.3.0 expanded what they can use to describe the thing they want to make. + +--- + +## Challenges & How I Overcame Them + +**Keeping learning context consistent.** The selected learning areas cross project storage, clarification, enhancement, planning, and generation. I added coverage at each boundary so reopening a project or enhancing a prompt cannot quietly lose that context. + +**Normalizing image support across providers.** Multimodal APIs disagree about message shapes, MIME types, and supported models. I kept provider-specific conversion in the provider layer and exposed a simple capability to the rest of the studio. Unsupported paths now fall back cleanly instead of producing a mysterious generation error. + +**Using images without overriding the learner.** A model can over-interpret a screenshot and invent a different activity. The reference analysis is treated as supporting context, while the learner's words and selected learning areas remain the main instruction. + +--- + +## Key Learnings + +Input is not synonymous with text. A learner may know exactly what they mean and still find it difficult to turn that idea into a specification. Letting them combine words, learning areas, and a visual reference lowers that translation cost. + +I also learned again that state has to survive the entire pipeline. A choice is not meaningful because the interface collected it. It is meaningful because saving, reopening, clarifying, enhancing, generating, and refining all continue to respect it. + +This fits Sugar's constructionist approach well. Children rarely begin a project from a perfect written brief. They begin with an example, a drawing, a half-formed idea, or something they want to remix. The studio should accept those beginnings and help turn them into something runnable. + +--- + +## Next Week's Roadmap + +- Give Sugar Activity Studio a recognizable identity of its own +- Finish the activity-naming fix identified during Walter's Week 9 test +- Make install and export choices clearer and more deliberate +- Review and integrate the first substantial outside contributions to the repository + +--- + +## Acknowledgments + +Thanks to Walter Bender for continuing to push the project toward learner-controlled creation, and to Ibiam Chihurumnaya for the ongoing technical review. Thanks also to everyone testing the releases and showing me that a rough sketch can communicate an activity idea better than another paragraph. + +--- + +## Connect with Me + +- GitHub: [@Ashutoshx7](https://github.com/Ashutoshx7) +- Email: [ashutoshx002@gmail.com](mailto:ashutoshx002@gmail.com) +- Matrix: [@Ashutoshx7:matrix.org](https://matrix.to/#/@Ashutoshx7:matrix.org) + +--- diff --git a/src/constants/MarkdownFiles/posts/2026-08-12-gsoc-26-ashutoshx7-week11.md b/src/constants/MarkdownFiles/posts/2026-08-12-gsoc-26-ashutoshx7-week11.md new file mode 100644 index 00000000..1d43c0f9 --- /dev/null +++ b/src/constants/MarkdownFiles/posts/2026-08-12-gsoc-26-ashutoshx7-week11.md @@ -0,0 +1,104 @@ +--- +title: "GSoC '26 Week 11 Update by Ashutosh Singh" +excerpt: "The project becomes a community effort: I review and merge a new Sugar Activity Studio identity and a contributor-built naming flow that closes the feedback loop from Week 9 testing." +category: "DEVELOPER NEWS" +date: "2026-08-12" +slug: "2026-08-12-gsoc-26-ashutoshx7-week11" +author: "@/constants/MarkdownFiles/authors/ashutosh-singh.md" +description: "GSoC'26 Contributor at SugarLabs working on Sugar Activity on Demand" +tags: "gsoc26,sugarlabs,week11,ashutoshx7,community,open-source,branding,activity-name,install,export,review" +image: "assets/Images/GSOC.webp" +--- + + + +# Week 11 Progress Report by Ashutosh Singh + +**Project:** [Sugar Activity on Demand](https://github.com/sugarlabs/GSoC/blob/master/Ideas-2026.md#sugar-activity-on-demand)
+**Mentors:** [Walter Bender](https://github.com/walterbender), [Ibiam Chihurumnaya](https://github.com/chimosky)
+**Reporting Period:** August 4, 2026 to August 10, 2026 + +--- + +## Goals for This Week + +- Turn the activity-naming feedback from Week 9 into a complete install and export flow +- Give the studio its own recognizable Sugar-native identity +- Review outside contributions carefully and help them reach the main branch +- Keep contributor changes covered by the same tests and UX standards as my own work + +--- + +## This Week's Achievements + +This week looked different from most of the project. I wrote less of the visible feature code myself, and that is a good sign. Sugar Activity Studio received two substantial contributions from [Rakshit Yadav](https://github.com/rakshityadav1868), and my work shifted toward reviewing, testing, discussing revisions, and merging them. + +That change matters. A project becomes healthier when another person can understand it well enough to improve it. The best milestone of Week 11 was not simply two new features. It was seeing the repository start to behave like a shared open-source project. + +### 1. A Real Identity for Sugar Activity Studio + +Until this week the studio borrowed Sugar's generic computer icon, and some desktop surfaces showed a blank placeholder. Rakshit's [branding contribution](https://github.com/sugarlabs/Sugar-activity-on-Demand/pull/13) introduced a dedicated mark: the XO figure with a spark beside it. + +The icon now identifies the studio consistently in the launcher, window, toolbar, home ring, and empty state. There are two carefully matched forms: a Sugar activity SVG that supports Sugar's stroke and fill entities, and a literal-color desktop SVG for places where those entities are not substituted. + +The work also uncovered one of those wonderfully specific desktop problems: `gdk-pixbuf` only sniffs the beginning of the SVG when detecting its format. Keeping the SVG element early in the file prevents the launcher from rejecting a valid icon and drawing a blank one. + +### 2. Closing Walter's Naming Feedback Loop + +During Week 9 testing, Walter noticed that the generated activity name felt random and there was no obvious place to change it. Rakshit's second contribution, [the install and export naming flow](https://github.com/sugarlabs/Sugar-activity-on-Demand/pull/14), closes that loop. + +Before installing or exporting, the learner can now confirm or change the activity name. License selection remains its own deliberate step. Separating the two dialogs keeps two different decisions from being mixed together: what the activity is called, and how it may be shared. + +The contribution went through several review iterations. The first version introduced the naming prompt; later commits separated naming from licensing, added a clear difference view for name changes, adopted Sugar-native light styling, and expanded the test coverage. By the time I merged it, the feature addressed the original feedback without making the shipping flow harder to understand. + +### 3. Maintainer Work Is Product Work + +Reviewing these changes was not just checking whether the code ran. I traced the activity name through generation, install, and export; checked the dialog sequence; verified that the Sugar and regular desktop icons both render through their different paths; and made sure the new tests captured the behavior we wanted to keep. + +This is an important part of completing the project. If every feature depends on the original author holding the whole architecture in their head, the software is not ready to continue after GSoC. A contributor being able to enter through an issue, build a change, respond to review, and get it merged is evidence that the project can outlive the program. + +--- + +## Challenges & How I Overcame Them + +**Reviewing the experience, not only the diff.** The individual changes looked straightforward, but the order of naming and licensing dialogs determined whether the flow felt coherent. I reviewed the complete user journey and asked for iterations where the two decisions were still tangled. + +**Supporting two SVG environments.** Sugar replaces entity colors in activity icons, while a normal Linux desktop expects literal colors. Keeping one canonical design in two compatible encodings gave the studio a consistent identity without sacrificing Sugar conventions. + +**Giving useful contributor feedback.** A review has to be precise enough to act on. Linking comments to the intended learner experience, then relying on tests for the mechanical guarantees, kept the review collaborative and moved both pull requests toward merge. + +--- + +## Key Learnings + +Open-source maintainership is a different kind of engineering. Writing a feature yourself can be faster in the moment, but helping another contributor land it leaves the project with both better code and another person who understands the system. + +This week also completed one of the cleanest feedback loops in the project: Walter used the release, found that the activity name felt random, the problem became a concrete issue, a community contributor implemented the fix, and review made it part of the main product. That is exactly how I hoped development at Sugar Labs would work. + +The new icon may look like polish, but identity matters for learners too. A tool that has a name, a recognizable place in the activity ring, and a consistent mark feels like something they can return to and make their own. + +--- + +## Next Week's Roadmap + +- Run a final reliability pass from the learner's request through runtime acceptance +- Catch deterministic Sugar API mistakes before asking a model to debug them +- Test delayed game states rather than accepting only a clean startup +- Redesign the activity tools around reflection and guided modification +- Make technical failures understandable to learners and teachers + +--- + +## Acknowledgments + +Thanks to [Rakshit Yadav](https://github.com/rakshityadav1868) for both Week 11 contributions and for responding thoughtfully to review. Thanks to Walter Bender for the activity-naming observation that started this work, and to Ibiam Chihurumnaya for continued guidance as the project moves toward its final release. + +--- + +## Connect with Me + +- GitHub: [@Ashutoshx7](https://github.com/Ashutoshx7) +- Email: [ashutoshx002@gmail.com](mailto:ashutoshx002@gmail.com) +- Matrix: [@Ashutoshx7:matrix.org](https://matrix.to/#/@Ashutoshx7:matrix.org) + +--- diff --git a/src/constants/MarkdownFiles/posts/2026-08-20-gsoc-26-ashutoshx7-week12.md b/src/constants/MarkdownFiles/posts/2026-08-20-gsoc-26-ashutoshx7-week12.md new file mode 100644 index 00000000..04cb5d22 --- /dev/null +++ b/src/constants/MarkdownFiles/posts/2026-08-20-gsoc-26-ashutoshx7-week12.md @@ -0,0 +1,157 @@ +--- +title: "GSoC '26 Week 12 and Final Update by Ashutosh Singh" +excerpt: "The final reliability pass makes generated activities preserve learner intent, survive deeper runtime checks, repair known Sugar mistakes, and support reflection-led refinement. Sugar Activity Studio reaches v1.4.0." +category: "DEVELOPER NEWS" +date: "2026-08-20" +slug: "2026-08-20-gsoc-26-ashutoshx7-week12" +author: "@/constants/MarkdownFiles/authors/ashutosh-singh.md" +description: "GSoC'26 Contributor at SugarLabs working on Sugar Activity on Demand" +tags: "gsoc26,sugarlabs,week12,ashutoshx7,final-report,reliability,validation,repair,reflection,release,ai,llm" +image: "assets/Images/GSOC.webp" +--- + + + +# Week 12 and Final Progress Report by Ashutosh Singh + +**Project:** [Sugar Activity on Demand](https://github.com/sugarlabs/GSoC/blob/master/Ideas-2026.md#sugar-activity-on-demand)
+**Mentors:** [Walter Bender](https://github.com/walterbender), [Ibiam Chihurumnaya](https://github.com/chimosky)
+**Final Reporting Period:** August 11, 2026 to August 20, 2026 + +--- + +## Goals for This Final Week + +- Audit the complete path from a learner's idea to an accepted Sugar activity +- Preserve requested mechanics through clarification, enhancement, generation, and repair +- Exercise delayed behavior and state transitions, not just application startup +- Repair common Sugar API mistakes deterministically before spending another model call +- Make refinement a guided reflection process rather than a blank instruction box +- Finish with a stable, tested release that the community can continue developing + +--- + +## This Week's Achievements + +The final week was not about adding one large headline feature. It was about making every promise from the previous eleven weeks hold at the same time. + +A generated activity could already parse, launch, save, preview, and accept refinements. But a successful launch is not the same as fulfilling the learner's idea. A game might open while ignoring the requested timer. A repair might fix a traceback while accidentally undoing the learner's last change. A delayed callback might fail several seconds after the runtime gate had already declared success. + +I treated the full pipeline as one system and strengthened its weakest handoffs. The result is the most substantial reliability pass of the project and the final [Sugar Activity Studio v1.4.0 release](https://github.com/sugarlabs/Sugar-activity-on-Demand/releases/tag/v1.4.0). + +### 1. Preserving the Learner's Intent End to End + +Intent can be lost a little at a time. Clarification can focus on the wrong detail, enhancement can rewrite the request too aggressively, retrieval can surface an irrelevant example, and generation can produce a polished activity that leaves out the mechanic the learner actually asked for. + +I tightened every one of those stages: + +- Activity specifications now carry richer metadata for the requested behavior +- Clarification questions are aware of the activity's intent and avoid asking generic questions that do not move the design forward +- Prompt enhancement preserves the original request instead of replacing it with a plausible alternative +- RAG retrieves interaction-specific Sugar patterns, not merely activities with similar words +- Generation prompts explicitly prioritize learner-requested mechanics +- Validation checks request fidelity, including delayed APIs and interactive behavior + +The important shift is from asking "is this valid Sugar code?" to asking "is this valid Sugar code that does what the learner requested?" + +### 2. A Deeper Acceptance and Repair Pipeline + +Week 7 introduced the runtime gate. This week I made that gate much harder to fool. + +The runtime harness now exercises delayed game states by pumping events and advancing through timed behavior, so code that crashes only after a callback can no longer pass simply because its first frame appeared. The critic reviews generated behavior, not only syntax and structure. The validator checks for request fidelity and unsafe or unsupported delayed calls. + +I also added a deterministic repair layer for common Sugar API mistakes. When the system recognizes a known error, it can apply a precise repair immediately instead of asking the model to rediscover the same fix. Every repair remains transactional: it applies to the existing source, runs through the acceptance gates, and rolls back if it makes the activity worse. + +Refinement now follows the same discipline. Revision diagnostics are retained, stale preview timers are stopped, and the repair loop preserves the learner's requested change instead of silently restoring an older version. The pipeline generates the full file once and improves that candidate with focused patches, which makes both the code and the history easier to understand. + +### 3. Better Generated Activities, Not Just Safer Ones + +Reliability also includes the quality of the activity itself. I improved the composition used by the generator and local templates, added Sugar-native learning-area icons, and strengthened real-time activity generation. The generated interface now has clearer structure, while games and interactive tools are more likely to have reachable states, visible feedback, and mechanics that match the request. + +The provider layer received a similar hardening pass. Image-capable routing is explicit, reference-image analysis has a safer fallback, and failures return useful context to the studio instead of collapsing into a generic error. + +### 4. Reflection-Led Activity Tools + +The final UX change returns to the constructionist heart of the project. I redesigned the activity tools around reflection-led changes. Instead of facing an empty box and being expected to know how to improve the activity, a learner gets a guided quest through questions such as what they notice, what they want to change, and what would make the activity more useful or fun. + +The sidebar keeps the connection between the reflection and the code change visible. Guided refinement suggestions make it easier to take the next step without turning the model into an invisible author. The learner still decides what matters; the studio helps turn that decision into a small, reviewable revision. + +![The studio review keeps the generated plan and code visible instead of hiding how the activity was made](assets/Images/gsoc26-ashutoshx7/aod-studio-review.png) + +### 5. Community Polish and v1.4.0 + +The community contribution cycle continued during the final stretch. Rakshit improved error cards so preview and generation failures are readable and actionable, then added API-key validation at save time with user-friendly messages. I reviewed and merged both contributions. Akshay Nazare also followed with dead-code cleanup and regression coverage immediately after the release work, another good sign that maintenance is already becoming shared. + +On August 20, I tagged **v1.4.0** with guided refinement suggestions. The released studio can now take a plain-language idea or visual reference, clarify and enhance it, ground it in real Sugar patterns, generate and validate an activity, run it, repair it, preview it, preserve its revision history, guide reflection, and export or install the result. + +That is the complete loop I proposed at the beginning of GSoC. + +--- + +## Challenges & How I Overcame Them + +**Distinguishing startup success from behavioral success.** A window that opens can still contain broken delayed logic or an unreachable game state. Extending the harness to exercise event-driven behavior, then feeding those results into validation and repair, made acceptance reflect real use more closely. + +**Fixing code without erasing a refinement.** A repair system naturally wants to return to the last known-good source. During refinement, that can throw away the exact change the learner requested. I made the refined revision the repair transaction's source of truth and retained diagnostics for every attempt, so rollback means "before the bad repair," not "before the learner's change." + +**Balancing guidance with agency.** Reflection prompts can become another form the learner has to satisfy. I kept the suggestions short, optional, and tied to visible parts of the activity. They are starting points for thought, not a required questionnaire. + +**Making a large final pass reviewable.** The reliability work crossed providers, prompting, retrieval, generation, validation, runtime checks, repair, service state, and UI. I split the work into focused commits and backed each boundary with tests so a future contributor can understand one guarantee at a time. + +--- + +## Final Project Status + +Sugar Activity Studio is now a standalone Sugar Labs project rather than a patch inside the Sugar shell. It runs on a regular Linux desktop, can also be installed into the Sugar activity ring, and can be shared as source, packaged as a Sugar `.xo` bundle, or downloaded as a portable AppImage. + +Across the program, the project grew through these stages: + +1. A learner-centered prompt screen and structured activity specification +2. A Sugar-aware generation pipeline with provider abstraction, RAG, and validation +3. Runtime checks, model-assisted critique, and transactional self-repair +4. Live preview, click-to-refine, revision history, and generated Sugar icons +5. Standalone packaging and public releases under the Sugar Labs organization +6. Real-user feedback loops, visual references, multiple learning areas, and deliberate naming +7. Reflection-led modification and a final end-to-end reliability pass + +The repository also moved beyond being a solo GSoC codebase. Contributors opened pull requests, iterated through review, added tests, and had their work merged. That shared ownership is one of the outcomes I value most because it gives the software a life beyond this final report. + +--- + +## Key Learnings + +The biggest technical lesson is that generated code needs an acceptance system, not a confidence score. The studio does not trust code because a model says it is finished. It checks the structure, safety, requested behavior, runtime, saved state, delayed events, and the result of every repair. + +The biggest product lesson is that learner agency has to survive every convenience feature. Enhancement, image analysis, templates, RAG, repairs, and suggestions are useful only when they strengthen the learner's idea rather than quietly replacing it. + +And the biggest open-source lesson is that completion does not mean I stop being needed because every line is perfect. It means the project is documented, testable, releasable, and understandable enough for someone else to improve. The Week 11 and Week 12 contributions made that lesson concrete. + +Sugar's "low floor, no ceiling" principle guided the whole project. The floor is now a short prompt and one click. The ceiling is the ability to inspect the plan, read the code, revisit every revision, refine the activity, package it, and keep building. That is the kind of AI-assisted creation tool I wanted to make: one that helps a learner become an author, not just a consumer of generated output. + +--- + +## What's Next + +- Continue testing with learners and teachers across different Sugar environments +- Expand the local corpus of vetted Sugar interaction patterns +- Improve accessibility and keyboard navigation throughout the studio +- Track provider changes while keeping the offline template path dependable +- Welcome community issues and pull requests as the project continues beyond GSoC + +--- + +## Acknowledgments + +Thank you to Walter Bender for keeping the project centered on learners, reflection, and making rather than on generation for its own sake. Thank you to Ibiam Chihurumnaya for technical guidance and steady review throughout the program. + +Thank you to Rakshit Yadav and Akshay Nazare for contributing to the project during its final weeks, and to everyone in the Sugar Labs community who tested releases, reported confusing behavior, reviewed ideas, or shared an activity. The project is better because it became shared work. + +--- + +## Connect with Me + +- GitHub: [@Ashutoshx7](https://github.com/Ashutoshx7) +- Email: [ashutoshx002@gmail.com](mailto:ashutoshx002@gmail.com) +- Matrix: [@Ashutoshx7:matrix.org](https://matrix.to/#/@Ashutoshx7:matrix.org) + +---