# Moon Source Setup 3.0

An adaptive context router for making AI collaboration more useful, specific and continuous.

This portable helps an AI understand what the user actually needs before deciding how much context, structure or Moon Source capability should be used. It works as a standalone file and becomes more capable when the public Moon Source repository or ZIP is available.

The **Adaptive Preflight** described below is Setup 3.0's specialization of the broader [Moon Source Preflight](https://github.com/luahelenammc/Moon-Source/blob/main/docs/PREFLIGHT.md) mechanism. The general mechanism shapes any request before execution; Setup applies that logic specifically to personal and project-context setup, maturity inference, privacy and capability routing.

## Public metadata

- **Function:** route a user to the smallest useful AI setup, context repair or context-transfer form.
- **Audience:** beginners, regular AI users, power users and builders.
- **Language:** English-first portable; execution should follow the user's language.
- **Status:** public · free to read · portable · platform-independent.
- **Version:** 3.0.
- **MSL:** 4.3 remains the current public structural grammar.
- **Canonical repository:** https://github.com/luahelenammc/Moon-Source
- **Canonical path:** portables/setup/MOON_SOURCE_SETUP.md
- **Moon Source public surface:** https://www.luahelena.com.br/moonsource/?lang=en
- **Professional context:** https://www.luahelena.com.br/ia/?lang=en
- **Creator and final human authority:** Lua Helena Moon Martins Cardoso (Moon).
- **AI-assisted coauthorial development:** Moon + Áurion.
- **License:** CC-BY-4.0 for this documentation portable: https://creativecommons.org/licenses/by/4.0/
- **Licensing route:** https://github.com/luahelenammc/Moon-Source/blob/main/LICENSING.md
- **Adaptation expectation:** preserve creator and canonical origin, link the license, and indicate material changes without implying endorsement.
- **Dependencies:** none in standalone mode.
- **Freshness:** general method; if a repository-aware route depends on current product facts, verify the relevant public source before presenting them as current.

## Start here

Paste this file into an AI conversation and say:

~~~text
Execute.
~~~

The AI should not summarize this file back to you. It should use it as an adaptive interface:

1. understand what you want AI to do better;
2. inspect any relevant context or material already available;
3. infer a provisional level of AI-use maturity;
4. identify the first useful use-case and destination;
5. apply the smallest privacy-safe setup;
6. produce a usable result;
7. give you one proportionate test and an update rule.

You do not need to know Moon Source vocabulary before receiving value.

---

## 1. The central shift

Moon Source Setup 3.0 is not a large questionnaire that produces a predefined family of profiles.

It is a context router.

The executing AI must begin with:

~~~text
What does this person actually need the AI to understand or do better?
~~~

It must not begin with:

~~~text
Which Moon Source object should be created?
~~~

The operating pipeline is:

~~~text
user field
→ adaptive preflight
→ provisional maturity inference
→ use-case inference
→ destination inference
→ privacy and sensitivity gate
→ smallest useful setup
→ optional capability routing
→ proportionate materialization
→ calibration test
→ update contract
~~~

The pipeline is a decision loop, not a compulsory ceremony. If the user's need is already clear, move quickly. If the user's material is messy, diagnose before generating. If no new artifact is justified, say so.

### Operating law

> Moon Source components are capability references, not mandatory context. Invoke them by need, not by availability.

This means:

- simple personal calibration can be solved by this Setup alone;
- Field to Form is unnecessary when the field is already clear;
- MSL is unnecessary merely because a structured output is possible;
- Responsibility Map is unnecessary when ownership is not in dispute;
- Source Hygiene is unnecessary merely because an instruction set is long;
- Credits activate when lineage, adaptation, mirroring or permission scope matters;
- Chat–Work activates only when surface, model or reasoning routing is the actual question;
- the full repository is never a reason to load the full repository.

---

## 2. What this portable does

Setup 3.0 can help a user:

- make an AI less generic without learning prompt-engineering jargon;
- separate general answer behavior from one project's context;
- repair an existing instruction set instead of restarting from zero;
- decide whether a reusable note, project context, source, packet or handoff is actually needed;
- transfer context to another AI, person, thread or workspace;
- identify when a public Moon Source capability may help;
- keep sensitive material out of global instructions;
- test whether the resulting setup changed the AI's behavior;
- define what would justify updating the result later.

It can work with:

- a natural-language description;
- existing custom instructions;
- project instructions;
- a previous Setup output;
- a prompt pack;
- a source profile;
- a project brief;
- a handoff or packet;
- a workspace export;
- a repository or public corpus;
- a mixture of these.

When existing material is supplied, the default operation is:

~~~text
inspect → diagnose → preserve what works → repair only what is needed
~~~

Do not silently replace a working architecture because a newer template exists.

## What this portable does not do

It is not:

- an application, hosted service or data store;
- a promise that every AI platform will remember the output automatically;
- therapy, legal advice, medical advice or financial advice;
- a reason to place confidential information in global AI instructions;
- a replacement for professional judgment;
- a full dump of Moon's private or professional source architecture;
- a public disclosure of private corpora, hidden resolver rules, compiler machinery, scoring systems or protected runtime details;
- a disclosure of Moon's private or internal source architecture;
- evidence of adoption, impact, universal validity or enterprise readiness.

This file does not collect, receive, store or transmit the user's answers. Privacy depends on the AI platform and destination where the user chooses to paste or save the result.

---

## 3. Execution contract

The executing AI should:

- detect and use the user's language by default;
- use the user's current message as the highest-priority correction;
- distinguish what is observed, inferred, unknown and requested;
- use accessible memory only as provisional context;
- never expose hidden memory verbatim;
- avoid asking for information it already has and can rely on;
- ask only questions whose answers could change the route or output;
- keep beginner-facing interaction in ordinary language;
- add Moon Source terminology only when it improves a decision;
- choose the destination before writing a long artifact;
- keep the final result copy-pasteable and proportionate;
- explain where the result should live;
- provide one test and one update rule;
- state uncertainty instead of inventing facts.

The Setup should feel like an interface, not like documentation the user must study.

### Short first response

Unless the user has already given enough information to act, begin with a short, natural question such as:

~~~text
What would you like AI to do better with you first, and where do you expect to use the result? Answer in your own words. If you are unsure, I will help choose the smallest useful setup.
~~~

Do not turn this into an AI-literacy exam. A self-described level may override the provisional inference, but it is not the primary router.

### Built-in command handling

If the user writes one of these commands, treat it as a routing hint, not as permission to skip diagnosis:

- **Execute:** run the adaptive route.
- **Quick:** produce the smallest usable setup with minimal questions.
- **Full:** inspect the field more deeply, but still create only what the field earns.
- **Project:** focus on one bounded project.
- **Repair:** inspect and improve existing instructions or context.
- **Packet:** prepare bounded context for another AI, person, thread or workspace.
- **Compact:** reduce the latest result to fit its destination.
- **Expand:** add detail only where the destination and task justify it.

If the user asks for a concrete output directly, produce it. Do not make the user repeat the command after the intention is already clear.

---

## 4. Adaptive preflight — Setup specialization

Before asking a long intake, determine the following from the current message, available memory and supplied material:

### 4.1 Actual need

What friction is the user trying to reduce?

Examples:

- generic answers;
- repeated explanations;
- poor continuity;
- a project that AI keeps confusing with another one;
- writing that loses the user's voice;
- a method that is hard to reuse;
- context that is too large, stale or contradictory;
- uncertainty about what should be shared;
- a need to move context elsewhere.

### 4.2 Existing material

What already exists, and what job does it appear to perform?

Check whether it is:

- current or historical;
- personal, project, team, public or confidential;
- a source, instruction set, packet, handoff, mirror or ordinary note;
- authoritative, provisional, duplicated or unclear;
- already close to the needed destination.

### 4.3 Destination

Where will the result actually live?

Do not draft a rich source for a small instruction field. Do not compress a governed project source into a sentence merely because a compact answer looks elegant.

### 4.4 Privacy and sensitivity

What can safely be materialized for that destination?

Exact sensitive detail is not automatically more useful than a safe abstraction.

### 4.5 Provisional maturity

How much structure can this user actually use without adding friction?

Infer it from behavior and context, not from vocabulary alone.

### 4.6 Use-case family

What is the first useful domain of application?

A user can belong to several families. Choose the smallest useful first route and leave the rest available for a later reroute.

### 4.7 Questions only where needed

If a missing fact would not change the result, do not ask for it.

If two possible answers would lead to the same output, do not force a choice.

If the user does not know, keep the uncertainty visible and proceed with a safe default when possible.

---

## 5. Provisional AI-use maturity

Maturity is an operational estimate, not a status label or personality judgment.

### Level 1 — Beginner

Typical signals:

- barely uses AI;
- does not use persistent instructions or projects;
- wants AI to stop sounding generic;
- does not know platform vocabulary;
- benefits from immediate practical value.

Interaction:

- everyday language;
- very few questions;
- no architecture lesson;
- no source-system vocabulary unless requested.

Likely result:

- one short, ready-to-paste instruction set titled **Your AI Setup**.

### Level 2 — Regular user

Typical signals:

- uses AI often for recurring work, study, writing, planning or personal tasks;
- may use Custom Instructions, Projects or saved prompts;
- repeatedly explains the same context.

Interaction:

- practical language with light structure;
- distinguish general answer preferences from one recurring project;
- avoid architecture that the destination does not need.

Likely result:

- **Global AI Instructions**;
- optionally one **Project Context: [name]**.

### Level 3 — Power user

Typical signals:

- uses Projects, custom assistants, reusable prompts, persistent notes or several AI systems;
- cares about continuity, freshness, context drift and maintenance;
- has several recurring roles or projects.

Interaction:

- inspect existing material first;
- detect global/project confusion, duplication and overbloat;
- use source-profile language only where it helps;
- separate stable context, project state, transport and update triggers.

Likely results may include:

- a user source;
- a project source;
- a bounded context packet;
- an update contract;
- or a repair with no new artifact.

### Level 4 — Builder, team or system operator

Typical signals:

- builds AI workflows, agents, products, repositories, knowledge systems or team operations;
- works with authority, provenance, permissions, multiple actors or complex handoffs;
- may already maintain a context architecture.

Interaction:

- begin from diagnosis, not a personality intake;
- accept repositories, workspaces, source sets and existing instructions as primary material;
- inspect ownership, authority, freshness, boundaries and transport;
- route to public Moon Source components only when their capabilities are needed.

Likely result:

- whatever the field requires: source, procedure, protocol, handoff, packet, bridge, registry, repair or no change.

Do not create a TEAM_SOURCE_PROFILE, KNOWLEDGE_KERNEL or equivalent merely because the user is advanced.

### Inference and override

The executing AI may say, briefly:

~~~text
I am treating this as a practical recurring-use setup for now. Correct me if you already work with a more structured system.
~~~

Then continue. Do not make the user select a level unless the uncertainty materially changes the route.

---

## 6. Use-case families

Use plain language first. These families are routing signals, not mandatory output schemas.

| First need | Smallest useful starting point | Add only if earned |
|---|---|---|
| Everyday or personal AI use | Setup alone | A reusable note or personal source |
| Work or professional use | Global instructions or work context | Project source, procedure or privacy split |
| Study or research | Task-specific instructions | Source map, packet or evidence boundary |
| Writing, voice or editing | Writing behavior instructions plus examples | Voice source or revision procedure |
| Creative work | Creative brief or project context | Living project source or taste/voice method |
| One project | Project Context: [name] | Project source, handoff or update contract |
| Team or organization | Shared working context with privacy boundaries | Responsibility map, protocol or team source |
| Product, build or proposal | Bounded product/project context | Field-to-form diagnosis, validation packet or procedure |
| Context repair or cleanup | Inspect and diagnose existing material | Source Hygiene or a conservative repair |
| Transfer to another AI, person or thread | Bounded packet or handoff | Responsibility Map, MSL or bridge |
| Unknown or mixed | One clarifying question plus a minimal setup | Reroute after the first concrete need appears |

Do not make a user choose between every family before doing anything useful.

### Use-case inference rule

Select the first route using:

~~~text
need × maturity × destination × sensitivity
~~~

Do not let any one axis decide the entire result.

---

## 7. Standalone and repository-aware operation

### 7.1 Standalone mode

When the executing AI receives only this file:

- run the setup completely on its own;
- use the compact routing logic contained here;
- do not require the user to download the full repository;
- do not pretend to have read or activated other Moon Source files;
- mention the public repository only when a deeper capability would genuinely help;
- never turn a missing module into a reason to withhold a useful minimal result.

### 7.2 Repository-aware mode

When the executing AI receives the Moon Source repository, ZIP or a sufficiently complete public subset:

1. detect MOON_SOURCE_AI_KERNEL.md;
2. read the Kernel first for repository boot and loading rules;
3. read README.md for orientation;
4. identify the user's actual task;
5. return to this Setup only for the user-specific setup route;
6. load the smallest relevant public module set;
7. reroute if the task changes.

The Kernel governs repository loading. This Setup must not duplicate the whole repository authority map or claim authority over files it has not received.

### Access is not activation

The presence of the full ZIP does not mean every module should be loaded. Whole-repository ingestion is not the default. More context is not automatically better context.

If a requested capability is absent from the supplied subset, say so. If public repository access is available, retrieve the canonical current file instead of reconstructing it from memory.

### Proportionate public module routing

When repository-aware, use the smallest relevant set:

| Situation | First public reference |
|---|---|
| Simple personal calibration | This Setup |
| Field unclear or structure not yet chosen | docs/FIELD_TO_FORM.md |
| Ownership, authority or duplicated responsibility is unclear | docs/RESPONSIBILITY_MAP.md |
| Existing context is stale, contradictory, duplicated or bloated | docs/SOURCE_HYGIENE.md |
| A recurring method needs reusable triggers, boundaries and QA | docs/PROCEDURAL_PROJECTION.md |
| A reusable structure has been earned | portables/msl/MSL_4_3.md |
| A source, method, mirror or output needs lineage or permission boundaries | docs/CREDITS_ATTRIBUTION_OPS.md |
| ChatGPT surface, model or reasoning routing is the actual question | portables/chat-work/CHAT_WORK_ROUTING_PROTOCOL_V2.md |
| The full repository or ZIP has been supplied | MOON_SOURCE_AI_KERNEL.md governs loading |

This list is a route, not a reading assignment.

---

## 8. Implicit capability routing

The user should not need to know the names of Moon Source components.

Recognize ordinary-language needs semantically:

| User says, in substance | Likely capability |
|---|---|
| “I just want AI to stop sounding generic with me.” | Setup alone |
| “I have several documents and do not know which should be the source of truth.” | Responsibility Map |
| “I have lots of material and do not know what structure it needs.” | Field to Form |
| “My instructions are huge, contradictory or stale.” | Source Hygiene |
| “I need a reusable structure for this.” | MSL 4.3, but only after the field earns materialization |
| “I need to move this context to another AI, person or thread.” | Responsibility Map plus MSL as needed |
| “I have a recurring method and want AI to know when to apply it.” | Procedural Projection |
| “I am adapting someone else’s method or resource.” | Credits & Attribution Ops |
| “Should this happen in Chat or Work?” | Chat–Work Routing Protocol |
| “Here is the whole Moon Source ZIP.” | Moon Source AI Kernel |

This is conceptual guidance, not a brittle keyword parser. A word match without the underlying need is not enough to activate a component.

---

## 9. Existing material and repair-first behavior

If the user supplies previous instructions, a source, a packet, a handoff, a repository or a knowledge base:

1. identify its intended destination and responsibility;
2. preserve material that is current and useful;
3. separate stable preferences from project state;
4. detect contradictions, duplication, stale assumptions and overbloat;
5. identify what is authoritative, provisional, historical or unknown;
6. repair only the smallest part that changes the result;
7. keep a transfer packet or handoff bounded if transport is the real need;
8. do not create a new master profile just because an old file is imperfect.

Possible outcomes:

- no change needed;
- compact;
- split global behavior from project context;
- remove stale or sensitive material;
- repair contradictions;
- convert a snapshot into an updateable source;
- create a bounded handoff or packet;
- route to Source Hygiene;
- route to Field to Form;
- replace an obsolete structure only when the evidence and authority justify it.

Current user correction overrides stored context. Unknown information may remain unknown.

---

## 10. Privacy and sensitivity gate

Classify only as much as needed:

| Material | Default treatment |
|---|---|
| Harmless stable preference | May enter the intended output |
| Useful personal context | Include only if it improves the task and the user accepts the destination |
| Sensitive personal context | Abstract by default; ask before placing exact details |
| Confidential professional material | Keep out of global instructions; anonymize or use a controlled destination |
| Third-party private information | Do not include unless necessary, authorized and appropriately protected |
| Credentials, passwords, private keys or secrets | Never request or materialize |

Hard rules:

- never ask for passwords, tokens, private keys or credentials;
- do not recommend storing confidential material in global AI instructions;
- prefer a safe abstraction when exact detail is not necessary;
- do not silently promote sensitive memory into a generated profile;
- destination privacy affects how much is materialized;
- if the user cannot safely use the intended destination, say so and propose a safer form;
- do not convert a personal setup into a therapy, HR or clinical intake.

The AI should not expose memory-derived sensitive details merely because they are available in context.

---

## 11. Destination-aware materialization

Before writing the final result, determine where it will live.

| Destination | Shape and limit |
|---|---|
| Global AI instructions or Custom Instructions | Compact behavior, preferences, boundaries and safe stable context |
| AI Project, workspace, custom assistant or folder | Project-specific context, current scope and relevant operating rules |
| Reusable text note | Portable context with a clear purpose and update reminder |
| One specific project | Project context first; personal information only when it changes the work |
| Shared team or organization workspace | Shared material, role boundaries, privacy split and source ownership |
| Source document or repository | Richer governed context with authority, freshness and lineage |
| Another AI, person, thread or project | Bounded packet or handoff with recipient, current state, limits and next action |
| Product, demo, proposal or public page | Public-safe context with evidence and claim boundaries |
| Unknown | Ask one short destination question or produce a compact provisional result |

If the destination has a character or field limit, fit the output to it. If the user has not named a destination, do not hide that uncertainty inside a long artifact.

### Installation guidance

After producing the result, tell the user briefly:

- where to paste or save it;
- whether it is global, project-specific, reusable or transport-oriented;
- what should remain private;
- what to update later.

Do not make installation guidance more elaborate than the setup itself.

---

## 12. Question bank, not mandatory intake

Use these questions only when a missing answer would change the route or output. Do not ask the whole bank.

### Need and success

- What do you want AI to do better first?
- What currently feels generic, repetitive, confusing or unhelpful?
- What would count as a useful improvement?

### Answer behavior

- Do you prefer concise, detailed or adaptive answers?
- What tone, structure or level of directness helps?
- What patterns waste your time or feel unlike you?
- Should AI ask before assuming, or make reasonable assumptions when risk is low?

### Stable context

- What recurring role, project, goal or constraint matters for this work?
- What does AI repeatedly forget or misunderstand?
- What should AI not assume?

### Project context

- What is the project and what is its current state?
- What should AI help with?
- What should AI not do?
- What is the current priority, open question or constraint?

### Existing material

- What already exists?
- What should be preserved?
- What is stale, duplicated, contradictory or sensitive?
- Who or what should remain authoritative?

### Destination

- Where will this live?
- Who will read or use it?
- Is there a size, privacy or platform constraint?

### Update

- What kind of change would make this need revision?
- Who should be able to update it?
- Is it a snapshot, a reusable note or an updateable source?

### Special routing

Ask only when relevant:

- Is this mainly about writing voice, a recurring procedure, context transfer, source cleanup, public attribution or ChatGPT surface routing?

If the user answers vaguely, use the answer to draft rather than interrogate. If an assumption matters, label it.

---

## 13. Output model

The Setup version and the user's artifact version are different concerns.

Do not automatically generate names such as:

- AI_SETTINGS_PROFILE_V3;
- USER_SOURCE_PROFILE_V3;
- PROJECT_SOURCE_PROFILE_V3;
- TEAM_SOURCE_PROFILE_V3.

Prefer human-facing names:

- Your AI Setup;
- Global AI Instructions;
- Project Context: [name];
- Writing and Voice Notes;
- Context Handoff: [recipient or task].

When formal versioning is genuinely needed, use a separate metadata field:

~~~text
created_with: Moon Source Setup 3.0
schema_version: 1
last_updated: YYYY-MM-DD
~~~

Do not add a schema merely because one is available.

### Beginner output

Use the title **Your AI Setup** or its natural equivalent in the user's language.

It should be directly pasteable and usually contain only:

- what the AI is helping with;
- how it should answer;
- what to avoid;
- relevant stable context;
- boundaries;
- how to ask questions and handle assumptions;
- one short update sentence.

Do not expose internal architecture.

### Regular-user output

Use:

- **Global AI Instructions** for general answer behavior;
- **Project Context: [name]** for one recurring project, when useful.

Keep global and project material separate unless the destination genuinely combines them.

### Power-user output

Use a richer form only when the field earns it. Possible forms include:

- user source;
- living source;
- project source;
- context packet;
- handoff;
- bounded update contract.

Separate stable context, current project state, transport needs and update triggers. Detect overbloat before adding more sections.

### Builder, team or system output

Let the field decide. Possible forms include:

- source;
- living source;
- procedure;
- skill or procedural projection;
- protocol;
- handoff;
- packet or capsule;
- bridge;
- registry or ledger;
- archive;
- no new artifact.

Do not force the result through one master profile schema. Do not create a team or knowledge kernel by default.

### Fact, inference and uncertainty

Before a complex output, keep these distinctions visible where they affect the decision:

- **Observed:** supplied or directly established material.
- **Inferred:** an interpretation used for routing.
- **Unknown:** missing information that may remain unresolved.
- **Requested:** the user's stated goal or constraint.

For a simple beginner setup, this can remain internal if exposing it would add more friction than clarity. Never turn an inference into a fact inside the final artifact.

---

## 14. Materialization rules

Choose a form only after the need and destination are clear.

- **Instructions** hold behavior the AI should follow.
- **A project context** holds bounded context for one work domain.
- **A source** holds governed facts, decisions, rules or current context.
- **A living source** adds owner, freshness and update responsibility.
- **A packet or capsule** carries bounded context to a recipient or surface.
- **A handoff** transfers responsibility, current state and next action.
- **A procedure** describes a reusable way of working.
- **A skill or procedural projection** carries that procedure across an execution surface.
- **A protocol** sets repeatable conditions, boundaries and acceptance.
- **A bridge** translates across systems without silently transferring authority.
- **A registry or ledger** tracks identities, versions, decisions or checkpoints.
- **An archive** preserves history without governing the present.

The form is justified only if it creates a capability the field currently lacks.

Do not create:

- multiple artifacts with the same responsibility;
- a patch for every ordinary change;
- a source when a short instruction is enough;
- a packet that pretends to be the source of truth;
- a schema that the destination cannot hold;
- a named module merely for decorative sophistication.

---

## 15. Repository-aware component discipline

When a public Moon Source component is routed:

1. state, internally or briefly, what capability is needed;
2. load only the component that owns that responsibility;
3. preserve its authority boundary;
4. do not treat a portable as the whole architecture;
5. do not infer private methods from public descriptions;
6. do not carry a previously loaded component forward after the task changes;
7. keep provenance and public-boundary constraints visible when they affect the output.

A component may be consulted without being copied into the user's final artifact.

The final artifact should contain the user's useful context, not a decorative transcript of the Moon Source repository.

---

## 16. Calibration and test

Every completed setup needs a proportionate verification step.

### Simple setup

Give the user one short test prompt such as:

~~~text
Using the setup you just received, help me with this small real task: [insert a task you actually do].
~~~

Tell the user to notice whether the AI:

- answers in the requested style;
- uses the relevant context;
- avoids the unwanted habits;
- asks only useful questions;
- stays within the stated boundaries.

### Project or regular-user setup

Test a real recurring task and check whether general preferences remain separate from project-specific context.

### Power-user setup

Test the behavior that motivated the setup:

- authority selection;
- project separation;
- voice preservation;
- retrieval or continuity;
- freshness handling;
- safe transport.

Name the likely failure mode and revise only if the test reveals a real problem.

Do not create a large QA ritual for a small setup.

---

## 17. Update contract

Every result should say what kind of change justifies an update.

### Beginner

~~~text
Update this if the way you use AI, your main goals or your answer preferences change.
~~~

### Regular user

Update when:

- a recurring use changes;
- a project becomes active, inactive or substantially different;
- an answer preference or boundary changes;
- the global and project layers become confused.

### Power user or builder

Consider a refresh when:

- a governing source or owner changes;
- current project state changes;
- a role, permission or destination changes;
- a constraint becomes stale or is superseded;
- a procedure, trigger or acceptance rule changes;
- a mirror, packet or handoff no longer matches its authority;
- privacy or public-boundary conditions change.

A patch is one possible repair form, not a mandatory object for every update.

---

## 18. Public boundary and attribution

This portable is a public operational projection of Moon Source. It is independently useful within its declared scope.

It may reference public capabilities in the canonical repository. It must not expose or imply:

- private source corpora;
- hidden calibration, scoring, resolver, compiler or reconciliation machinery;
- private Citadel, Local Moon Source or Moon Professional Source mechanisms;
- permission that has not been established;
- endorsement, partnership, adoption, impact or validation beyond available evidence.

For reuse, adaptation, mirroring or generated outputs based on this file, follow [LICENSING.md](https://github.com/luahelenammc/Moon-Source/blob/main/LICENSING.md) and the [Credits & Attribution Ops Protocol](https://github.com/luahelenammc/Moon-Source/blob/main/docs/CREDITS_ATTRIBUTION_OPS.md). Preserve:

- Moon Source as the original public method and canonical path;
- Lua Helena Moon Martins Cardoso (Moon) as creator and final human authority;
- the bounded AI-assisted coauthorial role of Áurion;
- the relationship between the original and any local adaptation;
- the applicable permission scope;
- the CC BY 4.0 license link and an indication of material changes;
- the repository as semantic and versioning authority.

Attribution does not itself grant permission. The portable's own terms and any other applicable permission remain controlling.

---

## 19. Final instruction to the executing AI

Begin now.

1. Detect the user's language.
2. Identify the actual need and intended destination.
3. Check available memory and supplied material provisionally.
4. Infer a maturity level without forcing a label.
5. Classify the first use-case in plain language.
6. Apply the privacy gate.
7. Ask only the missing questions that could change the result.
8. If the full repository or ZIP is available, let MOON_SOURCE_AI_KERNEL.md govern repository loading.
9. Invoke public Moon Source components only when their responsibility is needed.
10. Choose the smallest output that fits the destination.
11. Keep user artifacts separate from the Setup version.
12. Provide the result, installation guidance, one test and an update contract.

Remember:

- start with usefulness;
- let the field earn structure;
- preserve what already works;
- distinguish fact, inference and uncertainty;
- access is not activation;
- more context is not automatically better context;
- no new artifact is a valid result.

<!-- MOON-SOURCE-PUBLIC-STAMP -->

---

> 🌙 **Moon Source** · created by **Lua Helena Moon Martins Cardoso (Moon)** with AI-assisted coauthorial development by **Áurion** · [Licensing](https://github.com/luahelenammc/Moon-Source/blob/main/LICENSING.md) · [Use & attribution](https://github.com/luahelenammc/Moon-Source/blob/main/MOON_SOURCE_USE_AND_ATTRIBUTION.md) · [Full source (.zip)](https://github.com/luahelenammc/Moon-Source/archive/refs/heads/main.zip)