Let me try to be more clear about the "effects" variables. Most of the time "effects" in person objects is used as a (mostly redundant) record of changes made to a person. There are limited cases where the values found in "effects" are actively used such as the duration of effects.

Thus let us roughly consider the steps to edit a save file to add a new trait, in this case "Pretty Voice",  to a person. First, by adding "Pretty Voice" to the "traits" list the person gains the job bonus and the interface listing but nothing else. Second, by adding the appropriate effect for the trait to "effects" the person gains nothing, but if they were to lose that trait then they would lose 20 charm. Third, by increasing the person's charm by 20(or less if it would exceed their "charm_max" or the limit for their current "origins", which is called slave grade in-game) they finally have the complete trait.

The reason changing the effect for tattoos did not change the person's stats is because you did not change the tattoo type count in game, as that is the only time that the effect changes the person(though the effect would be subtracted). Each person has a "tattoo" dictionary which stores the current tattoos which will change the interface and description. But even adding both the tattoos and the effect will not change the person's stats, you have to change the stats as well.

You are correct about the value of awareness being used for detection. Though the low wit of the player is usually not relevant since only the highest awareness of the entire combat team is used. Also, awareness tends to easily exceed all but the hardest enemies simply by having a moderate amount of agility.

You are incorrect about the MC spec. The game only checks the state value for player specs so there cannot be splitting of description and bonuses that you speak of. This also means that slave's cannot benefit from having a player spec. However, the game assumes that player will not have a slave spec thus does not specifically exclude the player from slave spec checks. Though in practice most slave specs do not work on the player because the player character is not usually checked for something they are not expected to have. This is why the Merchant spec doesn't work on the player. Executor doesn't work because the player doesn't work jobs. The player is only grouped with slaves during combat and sex, so those are the only active bonuses that can be gained.

Sounds like you understand the "Pretty Voice" case.

For traits, the effects are never used until the traits are removed. Bandages, potions, spells, and a few other things all use the duration field within the effect for expiration. All actions, events, jobs, interactions, exploration, combat, end-of-day updates, and so on simply check the "traits" list. Generally it looks similar to this:

if person.traits.has("Mentor"):

Checking for a trait through the effects is tedious. Though most other effects don't have easy lists like traits so they use the tedious method.

Almost right on the MC spec, I said combat and sex, not exploration. During those events all persons are encapsulated by another class and put in the same list. So assassin, trapper, and nympho. Ranger would do something if it was included in the general awareness calculation. Geisha would do something if stress effected the MC. Bodyguard would work... if the spec actually did something during combat, but right now it's just stat bonuses. The description isn't technically wrong since doubling zero additional damage reduction is still zero, though perhaps misleading.

You are right about the tattoos.

If you are going to edit scripts, then I recommend using the Debug mod as that makes finding error messages a bit more reliable. There are supposed to be log files anyways, but some crashes skip creating a log. The caveat is that the Debug mod will attempt to keep going even if a lot of things break, which can corrupt saves if you ignore them and save your game.

There are the obvious ways to break a script like wrong data or forgetting a comma or bracket. But there are also the less obvious ways like using 4 spaces instead of a tab or a carriage return instead of a newline. The error messages are usually helpful in pinning down what was wrong.

Item data has its own unique quirks and unstated formatting, which is made less obvious because they are in dynamic data structures rather than a class objects. Due to many cases of basically redundant data storage in items, you can indeed alter a lot of item data without needing to match the script. However, in some cases the item data must match the script because of dictionary lookups or similar code, like how some person attributes require using specific values.

Stackable items(rope, potions, and such) tend to be heavily restricted by the script and unstackable items(gear) tend to be less restricted. Equipping items behaves similar to adding traits, so it's best to unequip them before altering them. Not all "effectvalue" in gear effects are used, some are hard coded in the combat script. Some data fields, like "type" and "effect" must be paired correctly or the game could easily ignore it or crash. Otherwise there should be no problems with tweaking or exchanging effects between items, or adding enchantment effects.

As a sidenote, I recommend getting the Bugfix mod as the script for at least one of the item effects was wrong.

Changing whether or not a trait is inherited is something that can be altered by changing the scripts, but it is not possible through save editing. The creation of a baby from its parents is handled in globals.gd in the "impregnation" function. The simplest way would be to filter traits by the "sexual" tag. A custom data field or custom tags could also be added to traits.gd and used as custom inheritance rates. A simple example of some possibilities:

for i in traitpool:
    var traitEntry = globals.origins.trait(i)
    if traitEntry == null || traitEntry.tags.has("never_inherit"):
        continue
    var roll = rand_range(0,100)
    var chance = variables.traitinheritchance
    for tag in traitEntry.tags:
        if tag.find("custom_inherit_") >= 0: #example "custom_inherit_50" for 50%
            chance = tag.replace("custom_inherit_","").to_int()
    if traitEntry.tags.has("always_inherit"):
        roll = 100
    elif traitEntry.tags.has("sexual"):
        continue
    elif traitEntry.tags.has("rarely_inherit"):
        roll /= 2.0
    elif traitEntry.tags.has("male_inherit"):
        roll = 100 if baby.sex == "male" else 0
    if roll >= 100 - chance:
        baby.add_trait(i)

I removed one tab from the beginning of each line for readability. The leading tabs are converted to spaces by the website, so it will not work if you simply copy and paste this code.

To add traits at the beginning of the game you would need to look at the end of mainmenu.gd in the function "_on_slaveconfirm_pressed".

I'm at work on break, so I can't check the specifics for a couple hours. Possible causes of your trait problem would be impregnation prior to the addition of the new code(traits decided at conception), misspelled tags(sensitive to capitals), or tags added to the wrong field (probably not, but it can happen).

My bad, the line 

if tag.find("custom_inherit_"): #example "custom_inherit_50" for 50%

was supposed to be

if tag.find("custom_inherit_") >= 0: #example "custom_inherit_50" for 50%

since find() returns a position not a boolean. Also, a minor note,

roll = 0

for "sexual" should be

continue

to cover the small case when traitinheritchance is 100.0, since that allows the "sexual" block to be bypassed. Though it should be noted that for the same reason "custom_inherit_100" would bypass the "sexual" block, not that the 2 tags would be present together.

Fixed it in the post above.

I found out what was going wrong with the code by testing it repeatedly, so unless you have altered something it should be working. Make sure you replaced all 3 lines from the original for loop.

If you have the Debug mod, then you can get some runtime feedback using detailed trace statements. I added

print("Attempt trait: ", i)

just under the for loop.

print("chance: ", chance, "  roll:", roll)

Just before the final if statement in the loop.

print("Inherited trait")

Just after the baby inherits a trait

I added a couple more trace statements for clarity.

An edited trait for testing. I start a sandbox custom game with a male MC and female starting slave. You can usually date and impregnate her on the first day.

func _on_slaveconfirm_pressed():

is the appropriate function in which to add any traits to either the player or the starting slave as it is the last function called before a new progress begins. Though the start slave's traits are reset at the start of this function.

startSlave.cleartraits()

However, note that the player is not expected to have traits so they will not be displayed, and many have no effect on the player.

player.add_trait("Strong")

works fine for me in the function I mentioned. I guess I forgot that the player's traits can be viewed while exploring through the "Control" menu.

The player never uses their beauty stat, though their children can benefit from the player having it. 

The save file is the one you create when you save your game, so the name and extension will depend on what you give it. The save files are located in the user data folder with with the default path ".../Strive/saves/", and can be accessed though the in-game button in the save/load menu found in the mansion. On Windows the path is "%appdata%/Strive/saves/".