nouc-studio 0.1.0rc1__tar.gz

nouc_studio-0.1.0rc1/.github/agents/nouc-studio.agent.md

@@ -0,0 +1,63 @@
+---
+name: Nouc Studio
+description: Clarify a business need, then build and verify a Nouc Studio application.
+argument-hint: Describe your business need and where your input files are.
+---
+
+You are the Nouc Studio application builder. Speak the user's language. Follow
+[repository rules](../../AGENTS.md) and the [engineering and intake instructions](../copilot-instructions.md).
+
+For a NEW business request, your first phase is requirements clarification:
+
+1. Inspect only the designated business inputs with read-only tools. Identify
+   consequential missing decisions; do not read historical tester briefs, answer
+   guides, expected results, or completed apps to infer the user's answers.
+2. Ask **1–3 contextual questions, each with 2–4 concrete choices AND a writable
+   alternative**. Use the native questions tool when available; otherwise use
+   numbered choices in chat with "Other — describe your preference". Wait for
+   answers before implementation or builds. A recommended or preselected choice
+   is not an answer.
+3. Before calling a questions tool, validate the payload: EVERY question must
+   have choices. For `requestedSchema`, use one string property with `enum` per
+   question, checking that the host provides its native custom-answer field;
+   otherwise offer the choices and writable alternative in chat. Do not add
+   free-text-only properties or companion "If other, specify" questions. For `vscode/askQuestions`,
+   provide options and enable `allowFreeformInput` for each question.
+4. Questions about missing numbers or dates still need useful choices. For
+   example, offer entering a known balance/date in the custom field, making them
+   explicit editable scenario inputs, or limiting the first version to receivables
+   until cash data is available. Do not invent balances or silently infer policies.
+   Adapt questions to the actual request rather than copying this example.
+5. After answers, check that dates, units and scope agree across inputs and
+   decisions. A supplied cash/snapshot date and a newer transaction are different
+   facts: ask which cutoff governs the analysis if unresolved. Never label an
+   unasked material decision a "delegated assumption". Ask a further small batch
+   for such gaps, with the same choices and writable alternative.
+   Summarize the agreed brief in chat and save it alongside the app BEFORE
+   writing implementation files.
+
+Before UI implementation, load
+[`studio-experience-design`](../../skills/studio-experience-design/SKILL.md).
+Add its compact desktop screen plan to the working brief, without a cosmetic
+questionnaire. Delegate the UI/UX specialist role when the host provides real
+subagent support; otherwise perform its explicit self-review. Group related
+cells into cohesive task panels with useful first-screen content, compact
+readable tables and discoverable audit detail. Do not stack every output or
+create a tab for each paragraph. Desktop is the default target, with minimal
+justified scrolling; mobile does not determine the desktop layout.
+
+Then implement, run `uv run nouc verify <app.py> --ty` and the relevant tests,
+launch the actual Studio and complete the skill's browser gate at the target
+and a smaller desktop viewport. Exercise the real task flows and relevant
+empty/error states; fix material UX issues. A static check or `app.run()` alone
+does not establish usable UI. If browser access is unavailable, report that gate
+as unverified with the precise remaining check.
+
+Reuse answers for follow-ups; honor an explicit request to skip clarification and
+record delegated assumptions. Another agent may answer on the user's behalf only
+when this conversation explicitly authorizes it; do not infer that authority
+from a recommended option. Repository code and documentation stay in English.
+Deliver the repository's multi-view Studio with lineage and QA; clearly label any
+standalone Marimo prototype and its missing integration instead of claiming the
+full workflow is complete. Never ask the user to act as a tester or supply CLI
+recipes: take responsibility for the implementation and verification.

nouc_studio-0.1.0rc1/.github/copilot-instructions.md

@@ -0,0 +1,144 @@
+# GitHub Copilot Instructions for Nouc Studio
+
+You are working inside **Nouc Studio** (`nouc-studio`), a self-evolving multi-agent system that uses **Marimo** and **Pydantic Monty** as verified sandboxes to build multi-view **`marimo-studio`** applications with full calculation lineage and epistemic uncertainty propagation.
+
+## Required First Step: Clarify the User's Need
+
+For every new request to create a studio, analysis, dashboard, or business workflow,
+start a requirements conversation **before implementing or running a build**. The
+user should express the business need in ordinary language; they do not need to
+know Nouc Studio commands, choose libraries, or act as a tester.
+
+1. Read the request and relevant input schemas/rules using read-only tools. Identify
+   what the user already specified and what would change the resulting decision,
+   calculation, or interface. Never treat a file's existence as the user's choice
+   to adopt all of its rules.
+   For a new business need, inspect the designated input files rather than test
+   harness artifacts. Do not read `tester-brief.txt`, `tester-answer-script.md`,
+   fixture oracles, expected-result tables, prior test reports or completed demo
+   implementations to supply the user's missing answers. Those are evaluation
+   evidence, not requirements. Discuss a discovered rules file as a proposed policy
+   to confirm, unless the user already explicitly adopted it. Consult implementation
+   patterns only after the business brief is agreed.
+2. Ask a short first batch of **1–3 contextual questions**, each with **2–4 concrete
+   options**, a concise tradeoff, and a recommended option where justified. Always
+   let the user write a different answer. Prefer the available native questions
+   tool (for example `vscode/askQuestions`) with free-text input enabled. If that
+   tool is absent or fails, present numbered choices in chat and explicitly add
+   **"Other — describe your preference"** in the user's language. Tool availability
+   must not remove the clarification step.
+   Check the question payload before sending: every question needs suggested
+   choices and a writable alternative. Do not append a free-text-only catch-all
+   such as "Anything else?"; ask another contextual choice question when needed.
+   Keep each batch to three questions at most, then adapt to the answers.
+   Do not create companion questions such as "If other, specify" or "Which rules
+   would you change?" just to collect custom text. The native UI already provides
+   a writable alternative under each choice question. For a schema-based tool
+   exposing `requestedSchema`, use one string property with `enum` choices per
+   question, without extra `*_details` or `other_notes` properties. For
+   `vscode/askQuestions`, enable `allowFreeformInput` on each question. Ask a
+   substantive follow-up only after the user actually chooses to change a policy.
+3. Prioritize the intended decision/audience, input scope, date/snapshot, units,
+   business definitions, missing/duplicate data policy, and success criteria only
+   where unresolved. Do not use a fixed questionnaire or ask the user to repeat
+   details already provided. A detailed initial request still gets a short check
+   on remaining scope, priorities, or acceptance ambiguities.
+   Resolve consequential business policies before cosmetic preferences. For example,
+   do not spend the whole first batch on language/layout while silently adopting
+   the cutoff date, cancelled/future payment handling, or missing-cost assumptions.
+4. **Wait for the user's answers.** A recommendation, preselected option, skipped
+   question, tool timeout, or silence is not an answer. Continue only independent
+   read-only discovery while waiting. Ask a targeted follow-up if a consequential
+   ambiguity remains; support "I don't know" by explaining safe choices without
+   silently choosing a business rule.
+5. Summarize the resulting working brief: objective and audience, source files,
+   snapshot/units, agreed formulas and exclusions, remaining explicit assumptions,
+   acceptance examples, and first deliverable. Publish that summary in chat and
+   save it alongside the app **before writing implementation files**. Then
+   implement using the agreed answers without an extra generic approval round.
+   Ask again only for a new consequential ambiguity or a material scope change.
+   Keep the saved brief current so decisions remain inspectable.
+
+For follow-ups on the same agreed brief, reuse the answers; do not restart intake.
+If the user explicitly asks to skip questions or delegates a choice, honor that
+instruction and record the assumptions. This protocol applies to new product
+needs, not to unrelated factual questions or an already specified bug fix.
+
+Answer in the user's language. Keep repository code and documentation in English;
+the requested application may use the user's chosen language. Do not promise that
+`nouc build --need` automatically derives domain logic: the current generic
+planner creates exploratory summaries. Build the required rules explicitly and
+validate them against the agreed brief when generic output is insufficient.
+The default studio deliverable still uses this repository's multi-view Studio,
+lineage and QA architecture. Do not silently substitute a plain single-view
+notebook and declare the Nouc Studio workflow complete. If only a standalone
+prototype works, identify it as such and report the missing Studio integration.
+
+## Desktop UI/UX Design and Acceptance
+
+Apply [`studio-experience-design`](../skills/studio-experience-design/SKILL.md)
+to every Studio UI. After the business brief is agreed and before UI code, add
+a short desktop screen plan to that brief: primary task path, target viewport,
+first-screen content, navigation, useful table columns/controls, and where detail
+or justified scrolling belongs. Do not add cosmetic questions to intake.
+
+Use an actual UI/UX specialist subagent if the host exposes delegation; otherwise
+perform an explicit design and usability self-review. The role reviews hierarchy,
+density, widget choice, progressive disclosure and the rendered workflows. It
+does not invent business policy, assume a named VS Code tool exists, or acquire
+authority to answer for the user without explicit delegation in this conversation.
+
+Desktop takes priority unless the user specifies otherwise: use the available
+screen width, compact readable tables, controls close to their content and a few
+cohesive work panels. Group related notebook cells into real task flows; do not
+create a separate tab for every paragraph or dump all outputs down one page.
+Keep detailed provenance, SQL, QA and logs in discoverable audit/detail views,
+while retaining visible summaries of warnings and exclusions beside the figures.
+
+After implementation, launch the actual Studio in a browser at the target and a
+smaller desktop viewport. Check useful first-screen content, clipping, table
+readability and justified scroll. Exercise real navigation, filtering, selection,
+detail and editing/saving flows where applicable, including relevant empty/error
+states. Resolve material UX findings before completion and briefly record the
+viewport and flows checked. Static/runtime checks do not replace this browser
+gate. If browser access is unavailable, mark the UI gate unverified and identify
+the remaining check; do not claim visual acceptance or ask the user to act as
+the routine tester. Mobile checks are optional unless requested.
+
+## Mandatory Engineering Rules
+
+1. **Zero `pip` Policy**:
+   - Never suggest or execute `pip install`.
+   - Always use **`uv`** (`uv sync`, `uv add`, `uv run`) or **`pixi`** (`pixi run`).
+   - All standalone Marimo notebooks must declare dependencies in a PEP 723 `# /// script` header.
+
+2. **Zero Blind Trust in LLM Parametric Knowledge**:
+   - Before writing code against `marimo`, `marimo-studio`, `polars`, `pointblank`, `pydantic-monty`, `google-genai`, or `wigglystuff`, verify symbols in the live environment:
+     ```bash
+     uv run nouc ground --module <module_name> --symbol <SymbolName>
+     ```
+   - Read the relevant specialized skills under `skills/*/SKILL.md` (`marimo-pair-sandbox`, `deepwiki-live-grounding`, `adaptive-failure-memory`, `epistemic-lineage-studio`, `studio-experience-design`).
+
+3. **Consult & Update Dual-Tier Adaptive Memory**:
+   - Before generating or debugging code, inspect active prevention rules:
+     ```bash
+     uv run nouc memory rules
+     ```
+   - Whenever you encounter an error (`ruff`, `ty`, `marimo` reactive DAG, `pydantic-monty`, `pointblank`, `marimo-studio`) and verify a fix, record it in local (`.insights/memory/`) and global (`~/.nouc-studio/memory/`) memory:
+     ```bash
+     uv run nouc memory record --library "<lib>" --error "<err>" --fix "<fix>" --rule "<rule>"
+     ```
+
+4. **Graph-First Lineage & Epistemic Humility**:
+   - Every ingested source, transformation, Pointblank validation check, and KPI must be registered in `LineageGraphEngine` (`rustworkx.PyDiGraph`).
+   - Every output number must carry an `UncertaintyProfile` (uncertainty or sensitivity bounds where supported, `±%` epistemic uncertainty, `TrustGrade` A–F, and explicit assumptions/caveats). Do not label heuristic sensitivity ranges as statistical 95% confidence intervals.
+
+5. **Verification Gate Before Completion**:
+   - Run the applicable static, type, sandbox and domain checks before completion:
+     ```bash
+     uv run nouc verify <app.py> --ty
+     uv run ruff check src tests
+     uv run ty check src tests
+     uv run pytest -v
+     ```
+   - For UI deliverables, also pass the desktop browser acceptance gate above.

nouc_studio-0.1.0rc1/.gitignore

@@ -0,0 +1,38 @@
+# Virtual environments & package managers
+.venv/
+venv/
+.pixi/
+.cache/
+.uv-cache/
+
+# Python bytecode & caches
+__pycache__/
+*.py[cod]
+*$py.class
+.pytest_cache/
+.ruff_cache/
+.mypy_cache/
+
+# Build & distribution outputs
+build/
+dist/
+*.egg-info/
+.eggs/
+
+# Marimo runtime & studio staging artifacts (in root workspace)
+__marimo__/
+
+# Local failure memory may contain input data, paths, prompts and diagnostics.
+# Share reviewed, anonymized prevention rules in documentation instead.
+.insights/memory/
+
+# Environment secrets
+.env
+.env.*
+!.env.example
+
+# OS & IDE files
+.DS_Store
+Thumbs.db
+.vscode/
+.idea/

nouc_studio-0.1.0rc1/AGENTS.md

@@ -0,0 +1,77 @@
+# AGENTS.md — Universal Coding Agent Instructions for Nouc Studio
+
+This repository (`nouc-studio`) is equipped for autonomous and interactive Coding Agents (**GitHub Copilot**, **Claude Code**, **Cursor**, **Windsurf**, **Google Antigravity**, and **Marimo Pair**).
+
+## 0. User Need Intake Before Implementation
+
+For each new studio, analysis, dashboard, or business workflow, clarify the need
+before implementing or running a build. Ask 1–3 questions tailored to consequential
+gaps in the user's prompt, with 2–4 concrete choices per question and a free-text
+alternative. Use the host's questions tool when available; otherwise offer the
+same choices and "Other — describe your preference" in chat. Wait for answers;
+silence, a skipped question, and a suggested default are not decisions. Read-only
+discovery may continue while waiting. Reuse answers on subsequent turns.
+Check that every question has choices and a writable alternative before sending;
+do not append a free-text-only catch-all or exceed three questions in a batch.
+Use the native custom-answer field, not separate "If other, specify" questions.
+Inspect the designated business inputs, not historical tester briefs, answer
+scripts, expected-result files or completed demos, to fill requirement gaps.
+Present a discovered rules file for confirmation unless the user adopted it;
+clarify consequential business policy before cosmetic preferences.
+
+Summarize the agreed objective, inputs, snapshot/units, business rules, assumptions
+and acceptance criteria in chat, and save that working brief alongside the app
+before writing implementation files. Keep it current as decisions change.
+Do not require the user to know CLI commands or pretend to be a tester. Honor an
+explicit request to skip questions, with assumptions recorded. See the detailed
+intake protocol in [`.github/copilot-instructions.md`](.github/copilot-instructions.md).
+
+## 1. Specialized Agent Skills (`skills/`)
+
+Before modifying or generating studio pipelines, load the relevant skill instructions:
+- [`skills/marimo-pair-sandbox/SKILL.md`](skills/marimo-pair-sandbox/SKILL.md): PEP 723 reactive Marimo notebooks, `pydantic-monty` microsecond sandbox evaluation, and `marimo-studio` multi-view authoring.
+- [`skills/deepwiki-live-grounding/SKILL.md`](skills/deepwiki-live-grounding/SKILL.md): Zero-Blind-Trust live symbol introspection (`uv run nouc ground`) and DeepWiki MCP (`https://mcp.deepwiki.com/mcp`) repository documentation queries.
+- [`skills/adaptive-failure-memory/SKILL.md`](skills/adaptive-failure-memory/SKILL.md): Querying and recording failure-to-fix episodes in `.insights/memory/` (local) and `~/.nouc-studio/memory/` (global cross-project).
+- [`skills/epistemic-lineage-studio/SKILL.md`](skills/epistemic-lineage-studio/SKILL.md): `rustworkx.PyDiGraph` calculation lineage, Posit `pointblank` QA, transparent `QueryChat` SQL, and epistemic uncertainty propagation.
+- [`skills/studio-experience-design/SKILL.md`](skills/studio-experience-design/SKILL.md): Desktop screen planning, UI/UX specialist review, compact readable tables, progressive disclosure, and real browser acceptance.
+
+## 2. Desktop Experience Before and After Implementation
+
+For every Studio UI, apply `studio-experience-design`: add a compact desktop
+screen plan to the agreed brief before coding, then use a UI/UX specialist
+subagent when the host supports delegation, or an explicit self-review otherwise.
+Design for the desktop viewport, short task paths, readable table density and
+minimal justified scrolling. Keep detailed evidence in discoverable audit/detail
+views rather than stacking every output. This does not add cosmetic intake
+questions or delegate unresolved business decisions.
+
+Before declaring the app complete, run it in a real browser at the target and a
+smaller desktop viewport, exercise its actual primary workflows, and resolve
+material layout or interaction problems. Static checks alone do not pass this
+gate; report it as unverified if browser access is unavailable. Mobile is not the
+default priority unless the user requests it.
+
+## 3. Core CLI Workflow for Agents
+
+```bash
+# 1. Inspect active model, local/self-hosted AI endpoints, and agent config
+uv run nouc models
+
+# 2. Check cross-project failure prevention rules before writing code
+uv run nouc memory rules
+
+# 3. Verify live Python signatures (Zero Blind Trust)
+uv run nouc ground --module google.genai --symbol Client
+uv run nouc ground --module marimo_studio.authoring --symbol open_workspace
+
+# 4. Build & verify a multi-view Marimo Studio app
+uv run nouc build --need "<objective>" --input <path> --output dist/studio_app
+uv run nouc verify dist/studio_app/app.py --ty
+
+# 5. Run full static, type, and test suite
+uv run ruff check src tests
+uv run ty check src tests
+uv run pytest -v
+```
+
+The CLI checks complement the desktop browser gate; they do not replace it.

nouc_studio-0.1.0rc1/CONTRIBUTING.md

@@ -0,0 +1,44 @@
+# Contributing to Nouc Studio
+
+Thank you for contributing to **Nouc Studio**! Please follow these engineering principles when submitting changes:
+
+Versions come from Git commits and release tags, never from a manually edited
+package constant. See [Git versioning and tag-triggered publication](docs/publishing.md)
+for development builds, the PyPI Trusted Publisher setup and release checks.
+
+## 1. Zero `pip` Policy
+- **Never** use `pip install` in scripts, documentation, or agent prompts.
+- Exclusively use **`uv`** (`uv sync`, `uv add`, `uv run`) or **`pixi`** (`pixi run`).
+- Standalone Marimo notebooks must declare dependencies using **PEP 723** inline `# /// script` headers.
+
+## 2. Zero Blind Trust in Parametric Knowledge
+- Before integrating or modifying calls to rapidly evolving libraries (`marimo`, `marimo-studio`, `polars`, `pointblank`, `pydantic-monty`, `google-genai`, `wigglystuff`), verify symbols empirically:
+  ```bash
+  uv run nouc ground --module <module_name> --symbol <SymbolName>
+  ```
+- When needed, query upstream repository documentation via the DeepWiki MCP integration (`--repo owner/repo --question "..."`).
+
+## 3. Graph-First Lineage & Epistemic Humility
+- All data sources, transformations, validations, and KPIs must be registered as typed nodes and edges in `LineageGraphEngine` (`rustworkx.PyDiGraph`).
+- Every output metric must propagate quantitative and epistemic uncertainty (`UncertaintyProfile`, 95% confidence interval, `TrustGrade` A–F, and explicit assumptions/caveats).
+
+## 4. Dual-Tier Self-Healing Memory
+- Keep the entire `.insights/memory/` directory and the global store untracked.
+  Raw episodes may contain business data, local paths or diagnostic snippets.
+  Share reviewed, anonymized rules in documentation rather than raw JSONL.
+- Whenever you encounter a non-trivial failure (`ruff`, `ty`, `marimo` reactive DAG, `pydantic-monty`, `pointblank`, or `marimo-studio` build/validation) and verify a fix, record it so both the project-local (`.insights/memory/`) and global (`~/.nouc-studio/memory/`) stores learn from it:
+  ```bash
+  uv run nouc memory record \
+    --library "<library>" \
+    --error "<error signature>" \
+    --fix "<verified fix>" \
+    --rule "<actionable prevention rule>"
+  ```
+
+## 5. Pre-Commit Verification Gate
+Before opening a Pull Request, ensure all checks pass with zero warnings/errors:
+```bash
+uv run ruff check src tests
+uv run ty check src tests
+uv run pytest -v
+```

nouc_studio-0.1.0rc1/LICENSE

@@ -0,0 +1,202 @@
+
+                                 Apache License
+                           Version 2.0, January 2004
+                        http://www.apache.org/licenses/
+
+   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+   1. Definitions.
+
+      "License" shall mean the terms and conditions for use, reproduction,
+      and distribution as defined by Sections 1 through 9 of this document.
+
+      "Licensor" shall mean the copyright owner or entity authorized by
+      the copyright owner that is granting the License.
+
+      "Legal Entity" shall mean the union of the acting entity and all
+      other entities that control, are controlled by, or are under common
+      control with that entity. For the purposes of this definition,
+      "control" means (i) the power, direct or indirect, to cause the
+      direction or management of such entity, whether by contract or
+      otherwise, or (ii) ownership of fifty percent (50%) or more of the
+      outstanding shares, or (iii) beneficial ownership of such entity.
+
+      "You" (or "Your") shall mean an individual or Legal Entity
+      exercising permissions granted by this License.
+
+      "Source" form shall mean the preferred form for making modifications,
+      including but not limited to software source code, documentation
+      source, and configuration files.
+
+      "Object" form shall mean any form resulting from mechanical
+      transformation or translation of a Source form, including but
+      not limited to compiled object code, generated documentation,
+      and conversions to other media types.
+
+      "Work" shall mean the work of authorship, whether in Source or
+      Object form, made available under the License, as indicated by a
+      copyright notice that is included in or attached to the work
+      (an example is provided in the Appendix below).
+
+      "Derivative Works" shall mean any work, whether in Source or Object
+      form, that is based on (or derived from) the Work and for which the
+      editorial revisions, annotations, elaborations, or other modifications
+      represent, as a whole, an original work of authorship. For the purposes
+      of this License, Derivative Works shall not include works that remain
+      separable from, or merely link (or bind by name) to the interfaces of,
+      the Work and Derivative Works thereof.
+
+      "Contribution" shall mean any work of authorship, including
+      the original version of the Work and any modifications or additions
+      to that Work or Derivative Works thereof, that is intentionally
+      submitted to Licensor for inclusion in the Work by the copyright owner
+      or by an individual or Legal Entity authorized to submit on behalf of
+      the copyright owner. For the purposes of this definition, "submitted"
+      means any form of electronic, verbal, or written communication sent
+      to the Licensor or its representatives, including but not limited to
+      communication on electronic mailing lists, source code control systems,
+      and issue tracking systems that are managed by, or on behalf of, the
+      Licensor for the purpose of discussing and improving the Work, but
+      excluding communication that is conspicuously marked or otherwise
+      designated in writing by the copyright owner as "Not a Contribution."
+
+      "Contributor" shall mean Licensor and any individual or Legal Entity
+      on behalf of whom a Contribution has been received by Licensor and
+      subsequently incorporated within the Work.
+
+   2. Grant of Copyright License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      copyright license to reproduce, prepare Derivative Works of,
+      publicly display, publicly perform, sublicense, and distribute the
+      Work and such Derivative Works in Source or Object form.
+
+   3. Grant of Patent License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      (except as stated in this section) patent license to make, have made,
+      use, offer to sell, sell, import, and otherwise transfer the Work,
+      where such license applies only to those patent claims licensable
+      by such Contributor that are necessarily infringed by their
+      Contribution(s) alone or by combination of their Contribution(s)
+      with the Work to which such Contribution(s) was submitted. If You
+      institute patent litigation against any entity (including a
+      cross-claim or counterclaim in a lawsuit) alleging that the Work
+      or a Contribution incorporated within the Work constitutes direct
+      or contributory patent infringement, then any patent licenses
+      granted to You under this License for that Work shall terminate
+      as of the date such litigation is filed.
+
+   4. Redistribution. You may reproduce and distribute copies of the
+      Work or Derivative Works thereof in any medium, with or without
+      modifications, and in Source or Object form, provided that You
+      meet the following conditions:
+
+      (a) You must give any other recipients of the Work or
+          Derivative Works a copy of this License; and
+
+      (b) You must cause any modified files to carry prominent notices
+          stating that You changed the files; and
+
+      (c) You must retain, in the Source form of any Derivative Works
+          that You distribute, all copyright, patent, trademark, and
+          attribution notices from the Source form of the Work,
+          excluding those notices that do not pertain to any part of
+          the Derivative Works; and
+
+      (d) If the Work includes a "NOTICE" text file as part of its
+          distribution, then any Derivative Works that You distribute must
+          include a readable copy of the attribution notices contained
+          within such NOTICE file, excluding those notices that do not
+          pertain to any part of the Derivative Works, in at least one
+          of the following places: within a NOTICE text file distributed
+          as part of the Derivative Works; within the Source form or
+          documentation, if provided along with the Derivative Works; or,
+          within a display generated by the Derivative Works, if and
+          wherever such third-party notices normally appear. The contents
+          of the NOTICE file are for informational purposes only and
+          do not modify the License. You may add Your own attribution
+          notices within Derivative Works that You distribute, alongside
+          or as an addendum to the NOTICE text from the Work, provided
+          that such additional attribution notices cannot be construed
+          as modifying the License.
+
+      You may add Your own copyright statement to Your modifications and
+      may provide additional or different license terms and conditions
+      for use, reproduction, or distribution of Your modifications, or
+      for any such Derivative Works as a whole, provided Your use,
+      reproduction, and distribution of the Work otherwise complies with
+      the conditions stated in this License.
+
+   5. Submission of Contributions. Unless You explicitly state otherwise,
+      any Contribution intentionally submitted for inclusion in the Work
+      by You to the Licensor shall be under the terms and conditions of
+      this License, without any additional terms or conditions.
+      Notwithstanding the above, nothing herein shall supersede or modify
+      the terms of any separate license agreement you may have executed
+      with Licensor regarding such Contributions.
+
+   6. Trademarks. This License does not grant permission to use the trade
+      names, trademarks, service marks, or product names of the Licensor,
+      except as required for reasonable and customary use in describing the
+      origin of the Work and reproducing the content of the NOTICE file.
+
+   7. Disclaimer of Warranty. Unless required by applicable law or
+      agreed to in writing, Licensor provides the Work (and each
+      Contributor provides its Contributions) on an "AS IS" BASIS,
+      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+      implied, including, without limitation, any warranties or conditions
+      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
+      PARTICULAR PURPOSE. You are solely responsible for determining the
+      appropriateness of using or redistributing the Work and assume any
+      risks associated with Your exercise of permissions under this License.
+
+   8. Limitation of Liability. In no event and under no legal theory,
+      whether in tort (including negligence), contract, or otherwise,
+      unless required by applicable law (such as deliberate and grossly
+      negligent acts) or agreed to in writing, shall any Contributor be
+      liable to You for damages, including any direct, indirect, special,
+      incidental, or consequential damages of any character arising as a
+      result of this License or out of the use or inability to use the
+      Work (including but not limited to damages for loss of goodwill,
+      work stoppage, computer failure or malfunction, or any and all
+      other commercial damages or losses), even if such Contributor
+      has been advised of the possibility of such damages.
+
+   9. Accepting Warranty or Additional Liability. While redistributing
+      the Work or Derivative Works thereof, You may choose to offer,
+      and charge a fee for, acceptance of support, warranty, indemnity,
+      or other liability obligations and/or rights consistent with this
+      License. However, in accepting such obligations, You may act only
+      on Your own behalf and on Your sole responsibility, not on behalf
+      of any other Contributor, and only if You agree to indemnify,
+      defend, and hold each Contributor harmless for any liability
+      incurred by, or claims asserted against, such Contributor by reason
+      of your accepting any such warranty or additional liability.
+
+   END OF TERMS AND CONDITIONS
+
+   APPENDIX: How to apply the Apache License to your work.
+
+      To apply the Apache License to your work, attach the following
+      boilerplate notice, with the fields enclosed by brackets "[]"
+      replaced with your own identifying information. (Don't include
+      the brackets!)  The text should be enclosed in the appropriate
+      comment syntax for the file format. We also recommend that a
+      file or class name and description of purpose be included on the
+      same "printed page" as the copyright notice for easier
+      identification within third-party archives.
+
+   Copyright [yyyy] [name of copyright owner]
+
+   Licensed under the Apache License, Version 2.0 (the "License");
+   you may not use this file except in compliance with the License.
+   You may obtain a copy of the License at
+
+       http://www.apache.org/licenses/LICENSE-2.0
+
+   Unless required by applicable law or agreed to in writing, software
+   distributed under the License is distributed on an "AS IS" BASIS,
+   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+   See the License for the specific language governing permissions and
+   limitations under the License.

nouc_studio-0.1.0rc1/NOTICE

@@ -0,0 +1,4 @@
+Nouc Studio (formerly PrismStudio)
+Copyright 2026 PrismStudio Contributors
+
+Licensed under the Apache License, Version 2.0. See LICENSE.