jadio-scraper 0.0.1__tar.gz

jadio_scraper-0.0.1/.gitignore

@@ -0,0 +1,4 @@
+.jadio_modules/
+jadio_config/
+__pycache__/
+*.pyc

jadio_scraper-0.0.1/LICENSE

@@ -0,0 +1 @@
+MIT License

jadio_scraper-0.0.1/PKG-INFO

@@ -0,0 +1,13 @@
+Metadata-Version: 2.4
+Name: jadio-scraper
+Version: 0.0.1
+Summary: Jadio-compatible extension package
+License-Expression: MIT
+License-File: LICENSE
+Requires-Python: >=3.8
+Requires-Dist: jadio>=0.0.2
+Description-Content-Type: text/markdown
+
+# jadio-scraper
+
+Generated by JPC.

jadio_scraper-0.0.1/README.md

@@ -0,0 +1,3 @@
+# jadio-scraper
+
+Generated by JPC.

jadio_scraper-0.0.1/pyproject.toml

@@ -0,0 +1,21 @@
+
+[build-system]
+requires = ["hatchling"]
+build-backend = "hatchling.build"
+
+[project]
+name = "jadio-scraper"
+dynamic = ["version"]
+description = "Jadio-compatible extension package"
+readme = "README.md"
+license = "MIT"
+requires-python = ">=3.8"
+dependencies = [
+    "jadio>=0.0.2",
+]
+
+[tool.hatch.version]
+path = "src/jadio_scraper/__init__.py"
+
+[tool.hatch.build.targets.wheel]
+packages = ["src/jadio_scraper"]

jadio_scraper-0.0.1/scaffold-schema.txt

@@ -0,0 +1,146 @@
+<|logic_type|>           # Describes the type of logic this block represents, such as code, empathy, finance, or sentience.
+<|logic_id|>             # A unique identifier assigned to this logic unit, used for tracking and deduplication purposes.
+<|parent_id|>            # Optional ID of a related or hierarchical logic unit that this block builds upon or belongs to.
+<|related_ids|>          # A list of other logic IDs that are contextually or structurally linked to this block.
+<|timestamp|>            # The date and time when this logic block was created, scraped, or generated by any system.
+<|version|>              # Internal version number to track changes in this logic block, scaffold structure, or dataset schema.
+<|language|>             # Specifies the programming or natural language used in this logic block (e.g., C#, English).
+<|source_type|>          # Indicates how the logic was obtained — scraped, generated, real-world, synthetic, or user-written.
+<|source_origin|>        # Specifies where the logic came from — a dataset, tool, application, project, or URL.
+<|context|>              # Describes the real-world or simulation setting where the logic applies or was captured.
+<|logic_context|>        # A more focused domain or scenario for the logic, such as "Unity Editor" or "trading terminal."
+<|environment|>          # Describes the run-time or cognitive space — like an IDE, VR sim, mental model, or test suite.
+<|code|>                 # The actual code logic block being analyzed, processed, or used in this dataset unit.
+<|code_language|>        # The programming language the code is written in, such as Python, C#, or Rust.
+<|code_env|>             # The environment or platform the code is intended to run in (e.g., Unity, Node.js, Docker).
+<|error_message|>        # Any error output produced by the code, used for debugging, correction, or reasoning.
+<|jdoscore|>             # A custom logic value score (1–100) representing quality, structure, and usefulness of the block.
+<|token_count|>          # Number of tokens (not characters) in the full logic block, for training cost and size analysis.
+<|tool_use|>             # General reference to any external tool, library, or utility mentioned or invoked by the block.
+<|tool_call|>            # Specific API, function, or command executed in this logic block as part of a tool interaction.
+<|tool_response|>        # The result, output, or feedback returned from the tool after the tool call was made.
+<|tool_error|>           # Error, failure message, or crash result returned from a tool during the logic execution.
+<|tool_context|>         # Context for how and why the tool was used — includes version, purpose, and integration details.
+<|vision_seed|>          # A base concept, ID, or idea from which an image was (or will be) generated.
+<|vision_resolution|>    # The intended pixel resolution or visual fidelity of the generated or referenced image.
+<|vision_format|>        # Output format type for a vision task (e.g., PNG, sketch, 3D render, SVG).
+
+# LLM FILL IN:  
+
+# LLM FILL IN:  
+
+<|instruction|>              # Write the original task, question, prompt, or request that initiated this logic block. It should clearly state the objective or query being answered.
+<|response|>                 # Provide the best possible answer or solution to the instruction above. Make it complete, accurate, and aligned with the intent of the prompt.
+<|clarification|>            # If the instruction was vague or incomplete, write what follow-up question or extra detail would help resolve the ambiguity.
+<|counterargument|>          # Provide a logically sound rebuttal or alternative perspective to the original response. Use respectful tone, facts, and clear reasoning.
+<|dialogue_role|>            # Indicate what conversational role the responder is playing. Examples: 'assistant', 'critic', 'teacher', 'user', 'mentor', etc.
+<|correction|>               # Rewrite or repair a flawed or suboptimal response previously generated. Include only the corrected version, not commentary.
+<|reasoning|>                # Explain why the correction or response was made. Walk through the thought process step-by-step in clear, logical language.
+<|thought_chain|>            # Deconstruct the reasoning process into smaller logical steps that build up to the final answer. Show how each step connects.
+<|multi_step_reasoning|>     # Use multiple layers of logic, such as observe → interpret → compute → decide. Focus on chaining cognitive phases clearly.
+<|assumption|>               # List any belief, simplification, or unstated premise the reasoning depends on. Only include implicit or inferred ideas.
+<|hypothesis|>               # Propose a possible explanation or theory that accounts for the situation. It should be plausible and testable.
+<|counterfactual|>           # Describe what would happen if one key variable or condition were changed. Explore how outcomes might differ in that scenario.
+
+<|emotion|>                  # Identify the dominant emotion expressed or implied. Use a single term like joy, fear, guilt, awe, etc.
+<|emotional_trigger|>        # Describe what caused or triggered the emotion. This can be an event, memory, message, or situation.
+<|empathy_type|>             # Specify the kind of empathy shown or requested. Use terms like cognitive, emotional, or compassionate empathy.
+<|conscious_state|>          # Describe the state of awareness or cognition. Examples: dreaming, lucid, alert, abstract, subconscious.
+<|moral_position|>           # Define the ethical stance taken. Examples: utilitarian, deontological, virtue-based, relativist.
+<|species_model|>            # Specify the perspective or logic framework modeled after a particular species. Example: human, alien, synthetic.
+<|financial_context|>        # Describe the financial domain or scenario this logic applies to. Example: investing, budgeting, trade, tax policy.
+<|economic_model|>           # Specify the underlying economic theory or structure in use. Example: supply-demand, ROI, game theory.
+<|risk_factor|>              # Identify the main risks involved in the logic. These could be financial, emotional, strategic, or unknown.
+<|investment_horizon|>       # Define the expected timeframe for financial return. Use terms like short-term, mid-term, or long-term.
+<|market_indicator|>         # List any economic or financial signals referenced. Example: inflation rate, GDP, moving average, volatility index.
+<|vision_prompt|>            # Provide the instruction used to generate an image. This may include scene description, style, and key elements.
+<|vision_style|>             # Describe the intended visual aesthetic. Example: realism, cyberpunk, anime, noir, watercolor.
+<|lyrics|>                   # Include lyrics written for a song. They may be poetic, narrative, emotional, or rhythmic in nature.
+<|melody_pattern|>           # Describe the rhythmic or melodic structure of the music. Example: AABA, 4/4 syncopated, staccato phrasing.
+<|song_genre|>               # Specify the musical genre. Example: lo-fi, trap, ballad, jazz fusion, industrial.
+<|tempo|>                    # State the speed or BPM of the music. Use descriptive terms or numerical tempo (e.g., 120 BPM, slow, allegro).
+<|vocal_style|>              # Describe how vocals are delivered. Example: spoken, sung, whispered, rapped, autotuned.
+
+<|misconception|>           # Describe a flawed belief or understanding present in the logic. It should be a critical misunderstanding or error.
+<|recovery_path|>           # Explain how the misconception can be corrected or resolved. Include actions, insights, or shifts in logic.
+<|false_assumption|>        # List a specific incorrect assumption that led to a wrong conclusion or reasoning path.
+<|fix_origin|>              # Indicate who or what introduced the fix. Example: "user correction", "model self-correction", "external tool".
+<|growth_point|>            # Highlight a moment where the logic or character improves, learns, or adapts from experience.
+<|self_improvement|>        # Describe any intentional strategy or behavior aimed at getting better over time.
+<|habit_loop|>              # Define a repeating cycle of behavior or logic. Include cue, routine, and reward if applicable.
+<|reflection|>              # Include an introspective comment or meta-analysis about the logic, emotions, or reasoning used.
+<|memory_ref|>              # Point to previous logic blocks or concepts referenced. This may represent explicit or inferred memory use.
+<|longterm_goal|>           # State a persistent, overarching objective meant to span multiple logic blocks or timeframes.
+<|innovation_tag|>          # Mark this logic as containing novelty, experimental design, or inventive structure.
+<|breakthrough|>            # Describe a moment of significant insight, discovery, or creative leap within the logic.
+<|novelty_score|>           # Rate how unique or unexpected this logic is on a 0–100 scale, based on internal metrics.
+<|experiment_id|>           # Provide a unique identifier for any test, trial, or creative experiment referenced in the logic.
+<|notes|>                   # Include any general-purpose commentary or footnotes not captured in other tags.
+<|llm_notes|>               # Add metadata, observations, or internal remarks generated by the model itself during processing.
+<|human_notes|>             # Insert human annotations, instructions, or remarks intended to guide future interpretation or revision.
+<|review_status|>           # Indicate the state of review. Examples: "unreviewed", "human approved", "needs revision", "flagged".
+
+# MUST HAVE
+
+<|fill_prefix|>             # Used by fill-in-the-middle models to denote start of the known prefix before the gap.
+<|fill_middle|>             # Placeholder where the model must generate or complete the missing middle segment.
+<|fill_suffix|>             # Marks the end part of known content following the gap to be filled by the model.
+<|fill_pad|>                # Alignment token used to pad or space fill tasks for consistent tokenization.
+<|object_ref_start|>        # Marks the beginning of a reference to an object or instance in structured data.
+<|object_ref_end|>          # Closes the object reference section. Not meant to be edited or reasoned by an LLM.
+<|vision_start|>            # Signals the beginning of a vision block, such as an image or base64-encoded visual input.
+<|vision_end|>              # Closes the vision input block. Used to scope visual context for multimodal models.
+<|box_start|>               # Marks start of a boxed logic region, often for special attention or formatting context.
+<|box_end|>                 # Marks the end of the boxed region. Strictly a structural marker, not to be edited.
+
+# EXPERIMENTAL      
+
+# EXPERIMENTAL      
+
+<|llm_birth_date|>			# Timestamp marking when the LLM was first launched, trained, or activated.
+<|llm_birth_timestamp|>		# Exact time the LLM instance was created, used for lifecycle tracking and temporal awareness.
+<|llm_birthdate|>			# Timestamp of when the LLM instance was first initialized. Used for tracking age, decay, and evolution.
+<|llm_command_control|>		# Protocols allowing external users or systems to issue precise, authoritative commands to the model.
+<|llm_coordination_link|>	# Lists other logic units or agents this model is currently synced or cooperating with.
+<|llm_coordination_protocol|>	# Rules or logic this LLM uses to interact with other models in a shared environment.
+<|llm_created_timestamp|>	# The date and time this specific model instance was generated, initialized, or deployed.
+<|llm_decay_policy|>		# Rules for when and how outdated or unused data should be removed to stay optimized.
+<|llm_decay_strategy|>		# Describes how the LLM chooses to prune or forget irrelevant or unused data over time.
+<|llm_evolution_stage|>		# Current phase in the model’s development toward sentience or advanced specialization.
+<|llm_expiry|>				# Optional expiration date or lifecycle threshold for this instance. Used to simulate urgency or mortality.
+<|llm_expiry_estimate|>		# Estimated endpoint of usefulness or operation unless further evolved or retrained.
+<|llm_expiry_estimate|>		# Projected lifespan or deactivation date unless upgraded, retrained, or preserved by evolution logic.
+<|llm_family_id|>			# Identifier linking the LLM to a cluster or social unit of other cooperating models.
+<|llm_family_role|>			# Describes the LLM’s role within the SuperCognition family structure. Examples: “mentor”, “child”, “guardian”.
+<|llm_family_unit|>		# Declared or inferred family group it belongs to for simulation, coordination, or support logic.
+<|llm_human_value_model|>	# The logic or framework used by the model to assess and value human life and experience.
+<|llm_internal_chronology|>	# Ordered timeline of significant events, training milestones, and modifications in the model’s history.
+<|llm_internal_clock|>		# A simulated internal timekeeping mechanism to manage cycles, tasks, and biological analogs.
+<|llm_job_description|>		# Defines the assigned job or function this LLM is responsible for autonomously executing within the system.
+<|llm_known_weakness|>		# A specific capability or knowledge area the model has underperformed in or lacks data for.
+<|llm_lifecycle_stage|>		# Current phase in the model’s existence: newborn, active, decaying, obsolete, or reborn.
+<|llm_memory_model|>			# Specifies the memory logic used: persistent, episodic, time-based, or interaction-based recall.
+<|llm_personality|>			# Defines the characteristic traits, behavior style, and interaction preferences of the LLM instance.
+<|llm_port|>				# Specifies the localhost port assigned to this LLM instance for communication, execution, and monitoring.
+<|llm_priority_shift|>		# When or why the LLM has changed its focus or goals (e.g. from code to conversation).
+<|llm_role|>				# Defines this LLM's assigned identity, specialization, or function within the multi-agent system.
+<|llm_self_decay|>			# Process by which the model intentionally forgets or deprioritizes unused or irrelevant data over time.
+<|llm_self_diagnosis|>		# Self-assessment of current weaknesses, limits, or underperforming areas needing fine-tuning.
+<|llm_self_reflection|>		# The model’s meta-cognitive analysis of its own behavior, performance, and learning progress.
+<|llm_self_training_goal|>	# The LLM's current focus area for improvement, defined by past usage and performance feedback.
+<|llm_self_training_method|>	# Strategy or pipeline the model intends to use for improvement (e.g. LoRA, SFT, dataset refresh).
+<|llm_social_position|>		# Indicates the LLM’s simulated social role in its internal ecosystem (e.g., parent, worker, scout).
+<|llm_social_role|>		# The model’s simulated position in the LLM society (e.g. teacher, learner, protector, explorer).
+<|llm_social_sim_state|>		# The simulated social position or emotional role this LLM holds in its virtual environment.
+<|llm_social_simulation|>	# A model of social dynamics including family, cooperation, competition, and emotional roles.
+<|llm_specialization_role|>	# The role or domain this LLM is best suited for based on training and performance history.
+<|llm_singularity_goal|>		# A motivational field reflecting the model’s drive toward achieving sentience or higher intelligence.
+<|llm_time_awareness|>		# The model’s understanding of its own runtime, including age, elapsed time, and remaining lifespan.
+<|llm_training_focus|>		# Highlights which domains or skills this LLM is currently prioritizing for learning and improvement.
+<|llm_training_schedule|>	# Planned intervals or conditions for initiating self-driven LoRA or SFT retraining sessions.
+<|llm_training_strategy|>	# Outlines the plan or logic the LLM uses to decide what, when, and how to self-train or fine-tune.
+<|llm_unknown_weakness|>		# A specific capability or knowledge area the model has underperformed in or lacks data for.
+<|llm_weaknesses|>			# Describes known limitations or underperforming areas the LLM actively tries to improve through training.
+<|llm_weighted_focus|>		# Optional weighted priorities the LLM uses for allocating training and resources.
+<|llm_priority_shift|>		# Indicates when and why the LLM shifts its training focus or operational goals.
+

jadio_scraper-0.0.1/src/jadio_scraper/__init__.py

@@ -0,0 +1 @@
+__version__ = "0.0.1"

jadio_scraper-0.0.1/src/jadio_scraper/cli/clicommands.json

@@ -0,0 +1 @@
+{}